要約

  • IETFは2026年8月28日、RPKI publication engineとRRDP・rsyncリポジトリの運用を扱うBest Current Practice案について、9月11日までの最終意見募集を始めた。現時点では承認済みBCPではない。
  • 新しいRRDP notificationは、参照するsnapshotとdeltaより先に公開してはならない。複数サーバーなら、一連の要求を同じ整合ビューに保つか、全サーバーへデータを配ってからどこか一つでも通知を公開する必要がある。
  • 新しいsessionやserialを見たことは、一つの応答点が索引を返した証拠にすぎない。全経路での取得、RPKI検証、RP出力、ルーター反映、転送結果は別である。

RPがロードバランサーから新しいnotificationを得る。次のserialとdelta URIがある。続く要求は別のサーバーへ送られた。そこにはnotificationだけがあり、deltaはまだない。404が返る。その後、切り離したはずのノードへのkeepalive接続が残り、serialが逆戻りしたように見える。

署名を破る必要はない。索引と中身の公開順を逆にするだけで、サービスは互いに矛盾する二つの現在を作れる。

8月28日の最終意見募集で問われている公開サービス案は、notificationを最後にするよう求める。締切は9月11日で、まだ最終合意でもRFCでもない。特定の運用者で事故が起きたと述べる文書でもない。

「参照できる」と「置いた」を同じ瞬間にする

RFC 8182では、notificationがsession、serial、snapshotとdeltaの場所を伝える。notificationを返す行為は、参照先も使えるという対外的な宣言になる。

一台なら、完全なデータを書き終えてからnotificationを差し替えればよい。複数台では二つの設計が考えられる。クライアントの連続要求を同じノードに固定し、そのノードの時間軸を守る設計。もう一つはsnapshotとdeltaを全ノードへ配り、最後にnotificationだけを一斉または段階的に解禁する設計だ。どちらも新しい索引と古い格納領域を組み合わせさせてはならない。

CDNも証拠面に入る。ファイル作成前の404をキャッシュすれば、新しいファイルが存在しても見えない。notificationを長くキャッシュすれば更新が隠れる。退役ノードに残るHTTP接続は古いsessionを返し続ける。オリジンのファイル一覧だけで公開面を証明することはできない。

RFC 8182はserialが後退した場合のRP動作を定めていない。製品によってはsnapshotを取り直す。それは復旧手段であり、大きい番号が新鮮で正しいことの証明ではない。

失敗したdeltaは負荷を段階的に増やす

deltaが取れなければ、RPはより大きいsnapshotへ移ることがある。それも失敗すればrsyncへ退避する。次回のRRDPでもsnapshotから始まるかもしれない。小さな順序ミスが、全量取得を繰り返す多数のクライアントを生む。

したがってトラフィック増加を単純な需要として扱えない。外部canary RPによる取得、snapshotへの予期しない切替、メモリー、ディスクI/O、容量を、session、serial、バックエンド、URI、HTTP結果と結び付ける必要がある。

参照されなくなったsnapshotとdeltaを二時間残す提案は、遅い取得と競合を吸収する。過去を残す措置であり、未来のファイルより先に出たnotificationは救えない。delta生成を一分より短い間隔にしない提案も負荷管理であって、公開順序の免除ではない。

RPKIの「公開」は複数の受領証から成る

CAは署名済み材料を作り、RFC 8181でpublication engineへ送る。更新前のlistで双方の状態を照合できる。複数PDUを一つのmulti-element queryにまとめれば、一組の変更が途中までしか反映されない危険を減らせる。

しかし受領証は統合できない。CAの記録は意図、RFC 8181応答はengineの受理、notificationは一つの端点の宣言、ダウンロードはバイト列の配送を示す。RPは証明書、manifest、CRL、署名オブジェクトを検証する。その出力がルーターへ届いたか、方針が採用したか、FIBが変わったか、パケットが別経路を通ったかはさらに後の事実だ。

取得成功したオブジェクトでもmanifestに載っていなかったり、ハッシュや証明書の検証で落ちたりする。有効なROAも、現在BGP経路が存在するとは述べない。Heng Luの現実の層を混ぜず、索引、バイト、検証結果、転送を別々に保存する必要がある。

rsyncには別の実装で同じ原則が現れる。読み取り中に木を更新すると、クライアントは新旧ファイルの混合を受け取る。完全な新ディレクトリを作り、時刻を整え、最後にsymlinkを切り替える方法なら、一つのsessionは一つの状態を見る。完成後に公開するという統治はRRDPと共通する。

serialが増えても内容が新しいとは限らない

serialは一つのsession内の順序を与える。時刻でも鮮度判定でもない。遅れた内容を増加serialで出すことはできるし、新serialのオブジェクトが検証に失敗することもある。

古いバックアップへ戻って内容が後退した場合、草案はRRDP session resetを要求し、依存CAへ完全な再同期を促す通知を勧める。resetは連続性が失われたという誠実な記録だ。失われたROA、publisher登録、期限間近のmanifestを自動回復するものではない。

動いているコードを優先するなら、設定画面ではなく実際の経路から全参照を取る。形式上の支配と実際の支配を分けるなら、notificationを止め、キャッシュを消し、古い接続を切り、sessionをresetし、旧ビューを保存できる主体を確認する。

notification-lastはRPKI検証を終わらせない。後続の検証が始められるよう、公開サービスの最初の約束を真にする。

Sources