要約

  • AS210833とFlorian Bauerの関係は、公開レジストリやネットワーク記録によって調査できるが、登録上の関係だけでは、日々ルーターを管理する人物、認証情報の保有者、障害復旧の責任者までは証明できない。
  • 今回確認できたのは、現在値を取得すべき公開ソースの構成である。ライブ取得ができなかったため、現在のプレフィックス、RPKI、上流、ピアリング、PeeringDBの値は未検証として扱うべきである。

問題は「誰の番号か」ではなく、どの層が何を証明するか

自律システム番号は、ネットワークを調べるための強力な索引である。しかし、索引と運用責任は同じものではない。RIPE Databaseのaut-numオブジェクトは、AS210833の登録名、状態、管理者、維持者、変更日時、宣言された import/export 方針を確認する候補になる。これらは登録上の責任や意図を示すが、記載されたBGPセッションが現在も稼働していることや、記載された人物が運用上の意思決定を行っていることを単独では証明しない。

RIPE Databaseのaut-num記録は、登録された自律システムの属性と宣言されたポリシーを確認する一次的な出発点である（RIPE Database aut-num object）。AS210833をoriginとして検索するroute6オブジェクトも、登録されたIPv6経路の候補を示す。ただし、route6オブジェクトは、経路が現在広告されていることや、RPKIで有効と判定されることを意味しない（RIPE route6 search）。

この区別は小規模ネットワークほど重要になる。登録情報が一人の人物や小さな組織に結び付いていても、設備の所在地、ホスティング事業者、上流契約、交換拠点のセッション、ルーターへの認証権限、バックアップ経路の管理主体は別々であり得る。したがって、人物名から運用能力へ直線を引くのではなく、各層が観測可能な事実を積み上げる必要がある。

経路が見えることは、経路を管理していることとは違う

RIPEstatのAnnounced Prefixes、Routing Status、BGP State、Looking Glassは、AS210833に関連する経路が観測地点から見えるか、どのプレフィックスが見えるか、どのASパスを通じて見えるかを確認するための異なる窓口である（Announced Prefixes、Routing Status、BGP State、Looking Glass）。

ここで得られるのは、特定の時点におけるコントロールプレーンの可視性である。複数の観測地点から同じプレフィックスが見えれば、単一のコレクターだけに依存する仮説より強い。しかし、それでも、発信元ネットワークがサービスを提供し続けられること、トラフィックを意図どおり処理できること、障害後にルートを戻せることまでは証明しない。

ASパスの直前に現れるASNを上流と解釈する場合にも注意が必要である。経路サーバー、兄弟ネットワーク、パス操作、部分的なコレクター可視性が、契約上のトランジット関係とは異なる見かけを作ることがある。BGPViewのprefix、upstream、peer APIは独立した比較材料になるが、関係の分類は観測方法と更新時点に依存する（BGPView prefixes、BGPView upstreams、BGPView peers）。

BGP.ToolsとHurricane Electricのプロファイルも、別の観測系としてプレフィックスや隣接ASを確認する候補である（BGP.Tools AS210833 profile、Hurricane Electric BGP Toolkit）。複数のサービスが同じプレフィックスとパスを示せば、現在の発信についての確信は高まる。ただし、データの生成時刻、収集範囲、更新遅延を揃えなければ、数値の違いをそのまま運用上の変化と解釈できない。

RPKIは認可を示すが、稼働と復旧能力を示さない

RPKIの役割は、特定のプレフィックスを特定のorigin ASが広告することを認可したかどうかを検証することである。Cloudflareの検証データをAS210833で絞り込めば、該当するROA、最大長、認可されたプレフィックスを調べられる（Cloudflare RPKI validator data）。

しかし、ROAが存在することは、その経路が現在広告されていることを意味しない。逆に、観測された経路がRPKI not-foundであっても、それだけで不正な運用だとはいえない。ROAは、経路の発信認可という狭い関係を証明する。ルーターを誰が管理するか、アドレス資源を誰が利用する契約を持つか、障害時に誰が変更を承認するかは、別の証拠を要する。

そのため、RPKIの検証は「運用責任者を特定する最後の証拠」ではなく、経路の認可層を切り分ける検査である。観測された正確なプレフィックス、origin AS、ROAの最大長、検証時刻を同じ記録に保存しなければ、validというラベルだけでは再現可能な結論にならない。

PeeringDBの宣言とBGPの観測を突き合わせる

PeeringDBは、ネットワーク名、ネットワーク種別、所在地、トラフィック規模、ピアリング方針、IPv4・IPv6プレフィックス数、交換拠点、施設、公開ピアリングアドレスなどを、運営者が申告する情報源になり得る（PeeringDB network record）。

この記録は、運用者がどのような接続面を公に説明しているかを調べるうえで有用である。ただし、自己申告メタデータであり、BGPで現在観測される経路や、実際に確立しているセッションと同一ではない。PeeringDBに記載された交換拠点が、現在のASパスに現れないこともある。反対に、観測された隣接ASNが、契約上のトランジットや直接ピアリングを意味するとは限らない。

運用責任を検証するには、少なくとも四つの時刻を揃える必要がある。登録オブジェクトの最終変更時刻、PeeringDB記録の更新時刻、BGP観測の取得時刻、RPKI検証データの生成時刻である。これらが揃わなければ、宣言が古いのか、経路が一時的なのか、収集系が異なるのかを判断できない。

今回の調査で分かったことと、分からないこと

今回の実行では、RIPE NCC、RIPE Database、PeeringDB、BGPView、BGP.Tools、Hurricane Electric、Cloudflare、CAIDAに関連する公開エンドポイントを特定した。CAIDAのAS Rankは、プロバイダー、ピア、顧客、組織、地域について周期的に推定された関係を比較する材料になる（CAIDA AS Rank）。しかし、調査時点ではライブのWeb検索またはHTTP取得が利用できず、各エンドポイントの現在の応答を取得できなかった。

したがって、今回の記事は「現在AS210833が二つのプレフィックスを広告している」「特定の上流や交換拠点に接続している」「RPKIで有効である」といった現在状態の主張をしていない。これらは、取得時刻と応答本文を保存して初めて検証可能になる。取得に失敗したことは、ネットワークが停止していることの証拠でも、運用責任が存在しないことの証拠でもない。現時点で確実に言えるのは、公開情報を運用上の結論へ変換するには、取得可能な証拠の連鎖が不足しているということである。

継続性を検証するための最小手順

AS210833の運用上の継続性を評価するには、単一のプロフィールページを見るだけでは不十分である。まず、RIPE Databaseのaut-numとroute6オブジェクトを保存し、登録者、maintainer、ポリシー、変更時刻を記録する。次に、RIPEstatのAnnounced Prefixes、Routing Status、BGP State、Looking Glassを同じ時刻帯に取得し、観測されたプレフィックスとASパスを保存する。

そのうえで、BGPView、BGP.Tools、Hurricane Electricの結果を比較する。各サービスのデータ時点が異なる場合は、差を矛盾として処理せず、観測窓と収集範囲の違いとして記録する。PeeringDBの宣言は、観測された経路と対応するか、更新日時が十分に新しいかを確認するために使う。最後に、CloudflareのRPKIデータから、観測された正確なプレフィックスとorigin ASの組み合わせを照合する。

この手順でも、運用責任の完全な証明にはならない。そこからさらに、設備やホスティングの管理記録、上流契約、インシデント対応の証拠、変更権限、復旧テストの記録が必要になる。ただし、公開情報だけで評価できる範囲を、登録、宣言、観測、認可、継続性という別々の層に分けられる。

結論

Florian BauerとAS210833の関係について、公開記録は調査可能な入口を提供する。しかし、登録名はルーターの管理権限ではなく、宣言されたポリシーは稼働中のセッションではなく、観測された経路は復旧能力ではなく、RPKIの認可はサービス継続性ではない。

今回の現在値取得ができなかったことは、空白を推測で埋める理由にはならない。むしろ、次に必要な検証を明確にする。プレフィックス、origin、ASパス、ROA、PeeringDBの接続情報を同じ時刻軸で取得し、複数の観測系を比較することで、行政上の関連と技術的な運用責任の間にある距離を測定できる。そこまで確認できない限り、AS210833について責任ある結論は、登録上の関連と公開された技術的手掛かりを認めつつ、日常運用と障害復旧を担う主体は公開情報だけでは確定できない、という範囲にとどまる。