要約

  • 10月20日公開のOpenBSD 8.0は、rpki-clientがトラストアンカー制約をBGPsecルーター証明書に正しく適用する修正を記載した。
  • このローカル設定は一つの検証者が受け入れる資源範囲を絞る。アンカーの公開や、別の検証者の判断までは制御しない。

柵の検査対象に一種類が加わった

OpenBSD 8.0のリリースページは、rpki-client(8)がBGPsecルーター証明書へ制約を正しく適用すると記す。詳細な変更記録にも同じ修正がある。公開日は10月20日だ。

ポイントは「制約機能があるか」より「どの証明書を実際に検査するか」にある。BGPsecルーター証明書は、BGPsecで使う鍵とインターネット番号資源を結びつける。OpenBSDの記録は、この証明書種別への制約適用が8.0で正されたことを示している。旧版の対象範囲や、具体的な事故は記載されていない。確認できるのは実装修正そのものだ。

この変更はIETF SIDROPSの草案「Constraining RPKI Trust Anchors」が提案する考え方と重なる。-02版は、各RPKI検証者（RP）が、信頼するトラストアンカー（TA）にどの資源を署名してほしいかをローカルに定める方式を示す。終端エンティティ証明書に記載されたIPアドレスとAS番号を制約ファイルと照合し、許容範囲を外れれば、そのRPは署名オブジェクトを処理しない。

「全資源」という大きな鍵

草案によれば、五つの地域インターネットレジストリ（RIR）は通常運用でTA証明書の下に全資源を列挙している。レジストリの一時的な不整合、とりわけ資源移転時の検証失敗を避けるためだ。一方、RPから見れば、そのTAの署名権限は現在の保有資源より広く見えることがある。

.constraintsファイルはRPに二つ目の判断点を設ける。対応する.talと同じ名前のファイルが一つのTAを受け持つ。運用者はプレフィックス、アドレス範囲、AS番号をallowで許可し、denyで例外を切り出せる。拒否が優先され、allowに載らない資源は暗黙に拒否される。全インターネットを列挙して一部を除外する、といった逆立ちした作業は要らない。

ただし、設定ファイルの文法エラーには厳しい結果がある。草案はRPにファイル全体を拒否し、そのファイルで終端エンティティ証明書を検査しないよう求める。修復されるまで、そのTAに対するローカル制約の検査は働かない。構文確認、配布、更新の担当までがセキュリティ設計に入る。

対象はRFC 3779の拡張にIPまたはAS資源を明示するオブジェクトだ。ROA、ASPA、RSC、BGPsecルーター証明書が含まれる。署名TALやManifestは継承資源を使うため対象外の例に挙がる。このローカル規則は一つのRPの検証範囲を絞る。ルーターの経路採用は、データ連携と個別の経路ポリシーを通じて決まる。

標準化を待つあいだにコードは動く

現在の-02版は有効なInternet-Draftで、RFCではない。Datatrackerに表示されるSIDROPSの状態は「Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC」。草案は、RFCとして発行する段階で実装状況の付録を削除すると記している。

付録には、C版rpki-clientが2023年から既定で制約方式を有効にしていること、Rust版panda-rpkiとGo版の実装があることが記載されている。草案の著者は、三つの実装がOpenBSDの同じfixtureで同じ結果を出したと報告する。同じ付録は、IETFが投稿者提供の実装情報を検証していないとも明記している。これは報告された実装と共通テストの記録であり、独立した相互運用監査ではない。OpenBSDのマニュアルは、TAごとの.constraintsファイルとローカルのallow／denyを説明している。

8.0の修正は、長く存在する機能でも、一種類の証明書が別扱いになることを示した。公開記録に旧版の対象範囲と具体的なコード経路はない。この二つが分かれば、過去の運用への影響をより正確に測れる。現時点で確認できるのは、OpenBSDがBGPsecルーター証明書の制約適用を修正した事実だ。機能名だけを見て「全証明書を検査済み」と判断するのは早い。

小さなファイルの配布に半年

草案は、OSや第三者パッケージに制約ファイルを同梱する保守者へ、利用者の更新に半年かかる前提で考えるよう促す。RIRの資源保有や移転方針は変わる。ローカル一覧も意図した境界に追随しなければならない。古い許可リストは新たに正当となった資源を拒否し、欠落したルールは運用者が許可した範囲を越えて受け入れることがある。

NROの2026～2028年戦略は、Trust Anchor Constraints文書の作成を計画するRPKI作業に含めた。NROのRPKI Programは2025年にも、アンカー設定の懸念に応える案をコミュニティへ諮る目標を掲げた。制度側の文書化と、検証器の実装修正は別々に進む。OpenBSD 8.0は後者の最近の証拠だ。

運用者が確認すべき点は明快だ。制約ファイルは意図した資源範囲を表すか。正しいTALに結びついているか。パッケージ更新に追随するか。構文エラーなく読み込まれるか。使うすべての証明書種別で検査されるか。OpenBSDの一行は、最後の問いを備考欄に押し込めなくした。

出典