要約

  • RFC 8805 は、ネットワーク運用者が自ら公開するプレフィックス単位の粗い位置情報を定義し、利用者がヒントとして扱えるとしている。
  • RFC 9632 は署名済みファイルを対象アドレス資源の権限に結び付けるが、現実の位置の正確さは認証しない。
  • 確かな修正記録には、署名済み版、取得、反映、重複解決、実際のサービス結果が必要になる。

署名は通るが、地図は直らない

運用者がプレフィックスを別の都市へ移し、geofeed を更新して任意の RPKI 認証子を付ける。検証は成功する。それでも数日後、動画カタログ、不正検知、CDN 選択は旧都市を示したままだ。

署名が無意味なのではない。RFC 9632 が確認するのは、署名者が対象資源について権限を持ち、正規化されたファイルのバイト列が一致することだ。HTTPS は取得先を保護できるが、WebPKI は IP 資源の割当権限を認証できない。

RFC 8805 の CSV は、プレフィックスに国、地域、都市を対応させる。情報は意図的に粗い。利用者はヒントとして扱い、別の情報源を優先できる。発行者の権限と位置の正確さも別々に検証する。暗号検証は、ルーターや利用者が実際にどこにいるかを観測しない。

RFC 9632 は RPSL inetnum: の geofeed: 属性で発見方法を定める。その後の取得時刻、最長一致、他データとの統合、版の有効化は利用者の判断だ。頻繁なリアルタイム取得は推奨されないため、キャッシュ年齢とデータセット版も運用証拠になる。

調査では、一つのプレフィックスについて feed のハッシュ、署名、証明書範囲、発見オブジェクト、取得時刻、解析、重複処理、利用データセット、反映位置、外部観測をつなぐ。「署名有効」で閉じるのは認証だけである。

出典