要約

  • LACNIC Blogの解説は、martian、資源状態に関わるbogon、RPKI Invalidを別の概念として扱う。執筆者は見解が必ずしもLACNICを代表しないと明記している。
  • 三つはいずれもフィルタリングの対象になり得るが、特殊用途アドレス登録簿、資源状態のスナップショット、検証済みROAのキャッシュという異なる根拠と更新周期を持つ。
  • RFC 6811でInvalidは有効化されたROAデータとの関係で定義される。キャッシュごとの差はあり得て、結果に対する処置はローカルポリシーであり、経路検証ではない。
  • 集計を説明可能にするには、プレフィックスやピアを公開する代わりに、カテゴリ、データ時刻、観測範囲、ローカル処置を残す簡潔な受領記録が必要である。

集計が成立するのは区別を残す場合だけだ

運用者が複数のフィルタ判定を一つの画面に集約すること自体は合理的である。異常の監視、処理量の把握、当番への引き継ぎには、まず全体像が必要になる。ただし、その全体像が何を表しているかは、集約前の根拠を後から取り出せるかどうかで決まる。LACNIC Blogの解説は、この点で実務的な区別を提示している。

記事では、martianは特殊な用途のために予約されたアドレスに、bogonは委任・割当の状態が期待と異なる資源に、RPKI Invalidは経路のプレフィックスと起点ASに一致するROAの認可が見えない状態に結び付けられている。これをLACNICの方針と読むことはできない。著者Sergio Kleimanは自らの寄稿であることを示し、見解がLACNICを必ずしも代表しないと記している。地域全体で特定のポリシーが実施されていること、事故が発生したこと、ある量の経路が処置されたことも、この文章からは分からない。

分かるのは、同じ「除外」という表示の背後に異なる時計があるということである。martianに関しては、IANAのIPv4 Special-Purpose Address Registryが参照面になる。そこに示される性質を利用するなら、どの版または取得時点を基に判定したかを残す必要がある。時点がなければ、あるアドレスの扱いが永続的な属性だったかのように見えてしまう。

資源状態に基づくbogonには別の時計がある。記事は、資源が利用可能になり、委任され、割り当てられるにつれてデータ集合が変わると説明する。したがって、リストの判定には資源状態のスナップショットと観測時点の組が必要である。後日の割当は過去のリストを遡って書き換えないし、古いリストが使われていた可能性は別途調べるべきである。資源の変化、配布遅延、ローカルルールの効果を一つの数字に混ぜると、何を更新すべきかも分からなくなる。

RPKIの時計は、依拠する検証済みキャッシュの視点で動く。RFC 6811では、検証済みROAのペイロードが経路を覆う一方で、そのプレフィックスと起点ASに合致する認可がない場合にInvalidとなる。RFCは、更新と取得のタイミングによってローカルキャッシュが異なり得ることにも触れている。そして二つの線引きがある。Invalidという結果に対して受理、記録、優先度変更、拒否のいずれを選ぶかはローカルポリシーであり、起点の検証はASパス全体を検証するものではない。

このため、三種類を含む総数は運用上の入口にはなっても、原因、危険度、責任、修復済みという結論にはならない。全てが同じ装置で観測されたとしても、根拠、取得時点、処置を決めた主体は同一ではない。

開示すべきなのは経路ではなく受領記録

説明可能性のために、BGP表、プレフィックス、AS番号、ピア名、顧客、機器設定、チケットを公表する必要はない。各カテゴリについて、データ源と版またはスナップショット、取得時刻、観測時刻、IPv4/IPv6、入出方向、広い隣接者区分、ローカル処置、例外類型、集計数、更新周期、訂正窓口を残せばよい。

この最小限の受領記録は、プライバシーと運用安全性を守りながら、後から変化を点検できるようにする。特殊用途の属性なら登録簿を確認する。資源状態ならスナップショットを更新する。RPKI Invalidなら認可の関係やローカル例外を調べる。それぞれの作業面を混同しないことが、単一の集計値を過剰に読ませない条件になる。

情報源