要約

  • ROA の EE 証明書には IP 資源拡張が必要で、inherit は禁止される。一方、AS 識別子委任拡張は存在してはならない。
  • 許可対象の AS は署名済み asID に記録される。これはアドレス権限者の認可であり、AS 運用者の認証や否認防止ではない。
  • オブジェクト検証、VRP、BGP 観測、ルータ受領、ローカル方針、経路選択、パケット到達を別々に記録する必要がある。

美しいオブジェクトに足りなかったもの

二つの ROA が同じプレフィックス集合を異なる順序で持っていた。監査担当者は、どちらが本物かと尋ねた。RFC 9582 の正規化はこの問いの一部に答える。AFI、先頭アドレス、プレフィックス長、実効最大長の四値で並べ、同一タプルを重複とする。

しかし、正規形は意味の表現を一意に近づけるだけだ。誰が AS を運用しているか、ルートが現在存在するか、どのルータがデータを受け取ったかまでは証明しない。

その限界は証明書にも組み込まれている。EE 証明書は RFC 3779 の IP アドレス資源を持ち、ペイロードの全プレフィックスを包含しなければならない。inherit は使えない。ところが AS 識別子委任拡張は ROA では使わず、証明書に含めてはならない。

起点 AS は署名済みペイロードの asID にある。証明書が「このアドレスについて署名できる」と示し、ペイロードが「この AS に起点を許可する」と示す。二つを合わせても「この法人が AS を運用する」「この装置が BGP を発した」とはならない。

RFC 9582 自身が、ROA 用 PKI は認可を与えるが明示的な認証ではなく、否認防止を意図しないと述べる。AS 資源拡張を足すことは情報を豊かにするのではなく、プロファイルを壊す。

maxLength は権限の幅である

一つの ROA は一つの AS だけを許可する。複数 AS なら複数オブジェクトである。アドレス項目にはプレフィックスと任意の maxLength があり、省略時は完全一致だけ、指定時はその長さまでの more-specific を許可する。

したがって /24 と 26 は /27 を許可しない。RFC 9319 が広い値を慎重に扱うよう求めるのは、意図しない more-specific まで有効に見せる可能性があるからだ。それでも maxLength は AS の正体や経路の稼働を記録する値ではない。

正規化も同様である。ソート済みのタプルは比較可能性を上げるが、リポジトリの鮮度、バリデータの同期、RFC 8210 セッション、ルータ方針の実行を引き受けない。

ROA 検証の後に経路検証がある

まず RFC 6488 の署名オブジェクト検証を行い、証明書経路と内容を調べる。次に RFC 9582 固有の包含、inherit 不在、AS 拡張不在、構造適合を確認する。どれか一つでも失敗すれば ROA 全体が無効になる。

合格した内容から VRP を得て初めて、RFC 6811 の比較へ進む。受信した BGP 経路が持つプレフィックス、長さ、起点 AS と照合し、Valid、Invalid、NotFound を求める。ROA だけでは受信経路がないため、この判定は存在しない。

さらに状態は方針ではない。RFC 7115 と RFC 8893 はローカルな輸入・輸出処理を扱う。あるルータが Invalid を捨てても、別のルータや AS が同じ判断をした証拠にはならない。Valid が best path になるとも限らず、選択されても転送とサービス応答は未証明である。

緑色の範囲を言葉で限定する

運用記録は「この時刻、この trust anchor、このリポジトリ集合で、このオブジェクトがこの AS にこの範囲を許可した」と書くべきだ。「AS は認証済み」「安全な経路が稼働中」と短縮してはいけない。

Heng Lu の reality layers は、記号が物理状態を上書きする危険を示す。running code の観測とローカル判断を残すからこそ、最小の共通仕様は強くなる。RFC 9582 の狭さは欠陥ではなく、権限境界である。

出典