要約

  • AFRINICがホストするRoutinatorの画面には、BGPで見つかったオリジンASNを使ってプレフィックスを検査する機能がある。BGPで組を選ぶ処理と、RPKIで組を評価する処理が一つの結果になる。
  • 保存した例では、196.216.2.0/23に対してriswhoisがAS33764をexact matchとして返したが、その応答にBGPデータの更新時刻はなかった。RPKI応答はvalidと生成時刻を返した一方、BGPの出典と時刻は含めなかった。
  • 画面全体にはRPKI、BGP、各RIRの割り振りデータの鮮度が表示される。問題は非公開であることではなく、個々の検査結果に利用版が結び付かないことだ。
  • 入力、選択規則、BGPの出典・シリアル・時刻、Routinatorの版と検証シリアル、VRPの照合結果、応答時刻をまとめた「複合検証レシート」を提案する。

「ASNを探す」は前処理ではない

ネットワーク担当者がプレフィックスとASNを自分で入力した場合、問いは固定されている。その組が、検証済みRPKIペイロードのどれかに合致するかを確かめるだけだ。ASN自動検索を有効にすると、画面はまずBGPの観測から問いそのものを組み立てる。

この差は使い勝手の代償という話ではない。機能は有用だ。障害調査ではIPアドレスから始まり、現在見えているオリジンを知らないことが多い。手入力による取り違えも減る。さらに画面は、exact matchを使うかlongest matching prefixを使うかを利用者に選ばせる。暗黙のアルゴリズムを見える選択にした点は評価できる。

ただし選択がある以上、記録すべき判断もある。BGPの更新によってASNが変われば、RPKIオブジェクトが同じでも結果の対象が変わる。逆にROAが更新されれば、BGPの組が同じでも状態が変わり得る。マッチ方法を切り替えただけで、より具体的な経路を選ぶ場合もある。

画面に最後に出るvalidは、一枚の事実ではない。「このBGPビューが、この規則で、このASNを選んだ」と「このRPKI検証状態が、その組に一致するVRPを持っていた」という二枚の事実を重ねたものだ。

公開APIを読むと境界が見える

AFRINICのサービスは、元データの違いをかなり丁寧に示している。Data Freshness欄はRPKIとBGPを別行にし、AFRINICを含む五つのRIRの割り振りデータにも個別の時刻を表示する。Routinatorのstatus応答には版、検証シリアル、更新処理の時刻項目、トラストアンカー別の件数がある。検索側のstatus応答はBGPの出典をriswhoisとし、シリアルとlastUpdatedを公表する。

今回固定した例は、2026年9月12日の公開応答だけを対象とする。196.216.2.0/23の検索結果には、AFRINICの割り振りデータを示すメタデータと、riswhois由来のBGPメタデータが並んだ。後者はAS33764をオリジンとして示し、exact-matchと記録した。

その組をRoutinatorに渡すと、返答はvalidだった。一致したVRPも表示され、ASNはAS33764、プレフィックスは196.216.2.0/23、最大長は24だった。返答にはgeneratedTimeが付く。したがって、単なる緑色より多くの説明責任は果たしている。

一方、検索結果にはriswhoisのlastUpdatedがない。validity応答にはriswhoisもBGP観測時刻も、ASNを選んだマッチ方法もない。画面が関連プレフィックスを示す際に使った割り振りデータの版も、検証結果の中には残らない。

鮮度のページを同時に開けば、人はそれらを手で結べる。しかし数分後に調査担当者が開いたstatusは、すでに次の更新を指しているかもしれない。現在の全体状態を示すページは、過去の個別結果が何を利用したかを証明しない。

この例から言えないこと

境界を広げてはならない。validは、観測したプレフィックス長とオリジンASNに合うVRPが少なくとも一つある、というRPKIオリジン検証の分類である。経路全体の安全性、世界中での到達性、ルータでの採用、商取引上の権限、漏えいの不存在を保証しない。

AFRINICの割り振りデータも、RPKI判定を生成する権限ではない。資源の登録上の文脈や関連プレフィックスを示すために利用される。BGP観測、割り振り記録、VRPは互いに異なる主張であり、同じ画面にあるからといって同じ証拠にはならない。

一回の応答は全資源の調査でもない。誤判定、古い経路、障害、攻撃、会員の過失、内部ログの欠落は確認していない。確認できるのは、公開される個別応答の組み合わせに、BGP側とRPKI側の版を一緒に保存する仕組みが見えないことだけだ。

残すべき九つの項目

複合検証レシートは、運用ログを丸ごと公開するものではない。次の項目で足りる。

  • 利用者が要求したプレフィックスと、手入力したASNの有無
  • BGP自動検索の有効・無効
  • exact matchまたはlongest matching prefix
  • 選ばれたプレフィックス、ASN、BGPソースID
  • BGPソースのシリアルとlastUpdated
  • 文脈表示に使ったRIR割り振りソースの版
  • Routinatorの版、検証シリアル、完了時刻
  • 状態と、一致・ASN不一致・長さ不一致VRPのダイジェスト
  • 生成時刻、レシートのダイジェスト、訂正時の後継参照

同じJSONに入れるだけでは不十分で、権限を示す言葉も必要だ。RIPE RISはある観測点群からBGPを「観測」する。AFRINICのファイルは資源を「登録」する。Routinatorは組とVRPを「比較」する。ルータをどう扱うかを「決定」するのは運用者だ。

この区別を守れば、レシートはAFRINICに過大な保証を負わせない。むしろ「サービスがどこまで答えたか」を限定できる。利用者も、緑の画面をAFRINICによる経路承認と誤って説明せずに済む。

機密性も調整できる。公開情報だけの検査なら完全なレシートを保存できる。顧客対応に関係する場合は、内部チケットに全文を置き、外部にはダイジェスト、ソース版、時刻、結果区分だけを共有すればよい。

画面から持ち出された瞬間が勝負になる

ライブ画面の色は、その場の診断には向く。ところがスクリーンショット、変更申請、監査メモに移ると、結果は時間から切り離される。「AFRINICでvalidだった」という短文は、BGPの出典、Routinatorの版、運用者の判断を一つの権威にまとめてしまう。

更新されたページで過去を取り戻すことはできない。BGPは進み、RPKIリポジトリは再公開され、statusの時刻は上書きされる。再検索は新しい観測であって、古い観測の復元ではない。

AFRINICの画面が価値を持つのは、別々の証拠層を横断できるからだ。その横断地点に小さなレシートを置けば、便利さを損なわず、結果が権威へ膨張するのを防げる。

出典

制度上の位置付けはAFRINICのResource Certificationページ、検査機能はホストされたRoutinator UIで確認した。固定資料はRoutinator status、BGP・RIRソースstatus、サンプルのプレフィックス検索、対応するRPKI validity応答である。画面の役割はNLnet LabsのRoutinator UI文書にあり、観測したBGP検索と鮮度表示の実装は版付きUI bundleに表れている。