要約

  • ARINは2026年4月、信頼アンカー制約をRPKIの予定機能として示した。ただし、根拠となるIETF文書は現在もワーキンググループのInternet-Draftであり、実運用開始を示す資料ではない。
  • 効くのはレジストリの最新表ではなく、relying partyが実際に読み込んだローカルの.constraintsファイルである。途中の転送状態、コンパイル、配布、更新の遅れが境界を変える。
  • ソース、署名、資源集合、パッケージ、導入時刻、検証器、運用判断を結ぶ配布証跡なら、各ネットワークの最終判断を奪わずに原因を追跡できる。

最新版が二つある夜

転送処理が完了した直後、二人の運用者がそれぞれ「最新版」の制約を使っている場面を考える。一人は当日のリポジトリから新しいパッケージを導入した。もう一人は長期サポート版の承認済みパッケージを使っている。組織内の手続きに照らせば、どちらも最新版である。だが、検証器が許す資源集合は同じではない。

現在のIETF草案は、このずれを抽象論にしていない。OSまたは第三者のパッケージで制約一覧を配る保守者は、利用者の更新が六か月遅れる可能性を見込むべきだとする。六か月は実測された平均値ではなく、設計上の想定である。それでも、制約の実効時刻を決める主体がレジストリだけではないことを端的に示す。

資源保有データが新しくても、コンパイラが古い入力を使えば一覧は古い。コンパイルが新しくても、配布チャンネルが止まれば導入は古い。導入済みでも、ローカル上書きや検証器の違いが結果を変える。したがって「ARINの制約」という呼び方だけでは運用状態を特定できない。何が、どの経路で、いつ、誰の判断により読み込まれたかが必要になる。

ARIN 57が示した工程表

2026年4月のARIN 57では、エンジニアリング報告が信頼アンカー制約を公開RPKIサービスの予定改善に挙げ、時期はIETF標準化作業に依存すると説明した。続く資料はこの作業をNumber Resource Organizationの枠に置いた。既存の拡張統計は各レジストリ内の資源を示し、仕様策定中の拡張転送ログはRIR間の移動を示す。それらがIETF草案を支え、rpki-clientには実装があるという整理だった。

会議記録では、各地域レジストリの下に置くことが認められたネットワーク資源の一覧、すなわちRPKI内に構築するアクセス制御リストに似たものとして説明された。草案と動くコードが存在することは、実装可能性を高める重要な事実である。しかし、どのrelying partyがどの版を本番で有効にしたかを示す導入記録ではない。

中心文書のdraft-ietf-sidrops-constraining-rpki-trust-anchors-01は2026年8月9日付で、Datatracker上はSIDROPSワーキンググループの活動中Internet-Draft、IESG状態は「I-D Exists」である。RFCではない。NROの署名付き状態を設計するdraft-nro-sidrops-ta-constraints-00も草案である。標準化前にコードが存在することと、合意済みの運用制度が存在することは分けて扱わなければならない。

広い証明書は失敗ではなかった

制約が必要になった背景には、2017年に選ばれた可用性の工夫がある。ARINは同年9月、他のRIRと調整して信頼アンカー証明書を全資源形式へ変更した。発表では0/0と要約され、TAL自体は変更されなかった。RIR間転送で一時的な台帳不一致が起きたとき、下位のRPKI成果物が大量に無効化されるのを防ぐことが目的だった。

現行草案は、五つのRIRの信頼アンカー証明書がIPv4、IPv6、ASNの全資源を列挙していると説明する。この広さは、各RIRが全資源を行政的に管理するという主張ではない。転送中の不一致をまたいで暗号学的連続性を保つための余裕である。一方で、証明書は通常の保有範囲外についても技術的には発行できる。

ローカル制約は、その広い能力をrelying partyが予期する範囲へ狭める。RFC 6480は、どの信頼アンカーを選ぶかを各relying partyに委ねる。RFC 8211は認証局やリポジトリ管理者による不利益な行為を分析する。ここで扱うのは既知のARIN不正ではなく、設計上の能力を限定しようとする予防策である。

allowとdenyの先にあるもの

SIDROPS草案では、制約は特定アンカーが発行すると運用者が予想するIPプレフィックスまたは範囲、AS番号または範囲のローカルな和集合である。記法はallowとdenyを使う。拒否が優先され、同種エントリは重複できず、記載順に意味はなく、明示的に許可されない資源は暗黙に拒否される。

検査対象はエンドエンティティ証明書である。記載資源が制約内に完全に収まらなければ、処理を止め、証明書を無効とみなすべきだとする。ROA、ASPA、RSC、BGPsecルーター証明書、geofeedが対象になり得る。これらは証明書に資源を明示するからだ。資源を継承するマニフェスト、Ghostbustersレコード、署名付きTALは同じ検査の対象ではない。

OpenBSDのrpki-clientマニュアルでは、.talと同じベース名の.constraintsを置く形が示される。TALはアンカーへの入口であり、制約はそのアンカーに期待する範囲を表すローカル方針である。同じディレクトリにあっても、更新元と変更時刻は同じとは限らない。

さらに、一覧にはポリシー判断が入る。ARINコミュニティは地域間IPv6転送案ARIN-2019-4を取り下げたため、ARIN割当てIPv6が別RIRのアンカー下に現れるのは通常想定されない。私用、文書用、一部予約資源も、どのRIRアンカー下にも現れるべきではない。制約の生成は単純な統計ファイルのコピーではなく、例外を伴うコンパイルである。

日次統計が持っていない時系列

ARINの拡張委任統計は毎日更新され、NRO形式でIPv4、IPv6、ASNの配分を示す。ただしARINは、再割当てと再委任を含まないと明記している。各RIRの報告を合わせれば、重複や欠落、転送済みアドレスの状態、未割当て資源の行政責任を見つけられる。優れた原資料だが、そのまま検証器が読む制約ではない。

「日次」はARINがファイルを更新する周期だけを表す。資源イベントの発生時刻、コンパイラの取得時刻、パッケージの構築時刻、ネットワークの導入時刻は別である。保有量のスナップショットだけでは、移動の途中も表せない。ARIN 57が拡張転送ログの仕様策定に言及したのは、その不足を認識しているからだ。

移動前の表と移動後の表のどちらかだけを採れば、正しい移行期間を失う。早く切り替えすぎれば元アンカー下の正当な成果物を拒否し、遅すぎれば不要になった許可を残す。全資源アンカーが防いだ可用性の断層を、古い制約がローカルで再現する可能性がある。

二重保有が正しい期間

NRO草案は署名付きのResource Distribution State、Event、Consensusオブジェクトを提案し、初期資源集合は参加者間で互いに素であるべきだとする。転送を開始、受領者の受諾、移転元の確定に分ける点が重要である。

受諾後から確定前までは、二つのアンカーが同じ資源を保有すると扱える。受領者が対応する署名済み成果物を先に作り、到達性の空白を避けるためだ。確定後は受領者だけが制約検証上の保有者になる。誤った確定は記録を消して戻すのではなく、補償転送で返す。

受諾段階で作った一覧が二つのアンカーを許し、確定後の一覧が受領者だけを許すのは矛盾ではない。それぞれ別の時点に正しい。問題は、パッケージ番号だけではその理由が分からないことだ。転送ID、段階、入力ハッシュ、コンパイル時刻があって初めて、正当な時間差と誤りを区別できる。

署名付きNRO状態は上流の来歴を強くできるが、ローカル方針そのものではない。IETF草案も入力候補として扱い、各relying partyが独自の基準と日程で判断するとしている。RIR共同の行政的主張と、個別ネットワークのルーティング判断は接続されても同一化されない。

手渡しを一つずつ記録する

配布証跡には、まず入力ファイル、時刻、ハッシュを置く。仕様とスキーマの版、コンパイラの識別子、再現可能ビルドの参照も必要である。NROの署名付き状態を使ったなら、署名主体と検証結果を記録する。アンカーごとにIPv4、IPv6、ASNの集合ハッシュを分ければ、差分の種類も分かる。

転送資源にはIDと段階を付け、二重許可の期間を明示する。次にパッケージ名、版、構築時刻、配布チャンネルを記録する。導入時刻、ローカル上書きの来歴、検証器の実装と版、実際に読み込んだ制約ハッシュが、配布物を稼働状態へ結ぶ。

最後は結果である。制約を理由に受理・拒否されたオブジェクト数を種類別に記録し、期限や鮮度の警告、最後に正常と確認した状態、フォールバックとロールバックの判断を残す。誰がいつローカル判断を有効にしたかも必要だ。ハッシュと集計値を使えば、機密のルーター設定を公開せず比較できる。

この証跡は主語の誤りも直す。ローカル検証器が第三者作成の古い制約を読み、EE証明書を処理しなかったとき、「ARINがROAを拒否した」と表現するのは正確でない。レジストリは原資料を出し、NROは共同状態を作り得る。保守者がコンパイルし、検証器が判定し、運用者がルート方針を選ぶ。それぞれの行為を分けて記録すべきである。

証拠がまだ語らないこと

資料は、ARINがrelying party向け制約を本番展開したとは示さない。全検証器が同一のNRO一覧を読むとも、六か月古いパッケージが実在するとも、それが経路障害を起こしたとも示さない。六か月は計画上の想定で、日次統計には明記された対象外があり、転送ログ仕様はARIN 57時点で作業中だった。

制約で証明書が無効になっても、直ちに経路が撤回されるとは限らない。RPKI検証結果をルーティング方針へどう組み込むかは運用者の判断であり、他の有効オブジェクトや実装も結果に関わる。ここで提案する証跡はARINやIETFの現行要件ではない。分散した責任を観測可能にするための限定的な提案である。

出典