要約

  • Job SnijdersとRIPE NCCのTies de Kockは、2024年12月のIETF標準RFC 9697を共同執筆した。
  • 検証器が過去に見た通し番号とハッシュを保存し、古い差分の指紋が変われば警告して最新の完全スナップショットに戻る。

1774番の引き出し

RFC 9697の例では、更新通知の通し番号が1774から1775へ進む。ここまでは普通だ。異変は一つ前の引き出しにある。古い1774番のハッシュ値が、以前の通知とは違う。1773番は変わらない。番号札だけ残して、中身を入れ替えたようなものだ。RFCが示すのは動作を説明するための例で、特定の実事故の記録ではない。Job Snijdersとde Kockは、この小さな食い違いを検出手順にした。

RPKIの署名付きオブジェクトは、経路の起点ASを検証する材料になる。RRDPは、その配布を差分ファイルで進める。検証器は最初に全体のスナップショットを取得し、その後は足りない差分だけを取り込む。更新通知にはセッション、通し番号、ファイルのハッシュが並ぶ。静的ファイルとWebキャッシュを使える効率のよい仕組みだが、同じ番号の過去の差分が同じ内容であり続けることに支えられている。

取得時刻が異なる二つの検証器は、1774番として別々の内容を取り込みながら、同じセッションと最新番号を表示できる。その二つの値だけ比べる監視画面は一致を報告する。ローカルのリポジトリは一致していない。二人の提案は、前回正常に取得した通知の番号とハッシュの組を保存し、次の通知と重なる番号を照合することだ。古い番号のハッシュが変われば警告を出し、最新の完全スナップショットを取り直す。

Snijdersは配布のややこしさを早くから書いている。本人が2021年にAPNICで説明したrpki-clientの実装記録には、負荷分散されたサーバー間のずれが登場する。あるサーバーの通知が新しい差分を指しても、別のサーバーにはまだそのファイルがない。これはRFC 9697の古い差分の変異とは別の故障だ。どちらも、署名の後ろで動く配布の手順を軽視できないことを教える。

同期が割れたキャッシュは、認証局が撤回しようとした検証済みデータを残したり、必要なデータを落としたりする。RFCは、妥当なはずの経路が長くunknownやinvalidと判定される可能性を記す。セッションは数カ月続くこともある。昨日の番号に、昨日と同じ中身が入っているか。それを確かめるだけで、明日の判断が変わる。