要約

  • RFC 9986では、ISAACの認証値は256個ずつのページとして得られる。次のページを生成すると現在ページは失われ、この操作は元に戻せない。
  • ページを越えてパケットを検証する場合、受信側は先にISAACの全状態をコピーする。一致すれば新状態を採用し、不一致なら保存状態へ戻る。
  • この方式が示すのは、すでにUpの真正な送信側が生存信号を送ったことまでである。パケット全体やサービス経路の健全性ではない。運用証跡は秘密を残さず、採用と復元の両方を証明する必要がある。

判定前の入力に、判定器を進めさせない

BFDは短い間隔で制御パケットを交換し、隣接する転送装置の障害をすばやく検知する。全パケットに重い認証を課せば、暗号支援の乏しい装置では目的の速度を失いかねない。RFC 9985はそこで、状態変化を伴う重要な処理と、すでにUpのセッションを保つ処理を分けた。

RFC 9986のMeticulous Keyed ISAACは、後者のための低コストな方式である。共有秘密、セッション固有のSeed、BFDのDiscriminatorに由来する材料から疑似乱数列を作る。ISAACは32ビット値を256個単位のページで用意する。ページ内ならシーケンス番号に対応する値へ安く移動できる。最後を越えると、mixingを実行して次ページを作る。

問題は、その生成が単なる試し読みではないことだ。現在ページを壊し、元には戻せない。まだ正しさを証明していないパケットが次ページの位置を指したとき、受信側が唯一の状態を先に進めてから不一致に気づけば、拒否しても以前の正当な列へ戻れない。検証が、守る対象を自ら書き換えたことになる。

RFC 9986は順序を固定する。予想値の生成が新しいページを作るなら、受信側はその前にISAACの全状態を保存しなければならない。値が一致したときだけ保存コピーを捨て、新状態を正として使う。不一致ならコピーを復元し、試行で変化した側は破棄するか、正規状態から切り離して後の利用に備える。

信頼が成立するまでは、検証結果だけでなく検証行為そのものも巻き戻せなければならない。

パケット損失が認めるのは、範囲付きの先読み

未来の位置を見る理由は攻撃だけではない。途中のBFDパケットが失われれば、次に届くシーケンス番号は直前値より複数進んでいる。その差をページ内のindexとして使い、正しいAuth Keyが見つかれば、受信側は損失後に同期を取り直せる。

ただし先読みには上限がある。直前の受信番号が既知なら、許されるのは「直前値+1」から「直前値+3×Detect Mult」までで、32ビットの循環空間として扱う。外側なら破棄する。内側なら対応値を調べられるが、その位置が256個の境界をまたぐと保存規則が発動する。

運用ログが認証の成否だけを残すと、この構造は見えない。直前に受理した番号、受信番号、Detect Mult、算出窓、ページbaseとindex、mixingの有無を残すべきだ。一致時は「保存完了→生成→一致→新状態採用」、不一致時は「保存完了→生成→不一致→旧指紋へ復元」の順序が検証できなければならない。

もっとも、生のISAAC状態や秘密鍵を台帳へ書くわけにはいかない。復元不能なcheckpoint識別子やdigest、時刻、結果で十分である。証跡を公開した結果、次の認証値を予測できるようでは本末転倒だ。

本物の送信者でも、内容全体が本物とは限らない

ISAAC形式はAuth Key ID、シーケンス番号、Seed、32ビットの出力を運ぶ。認証種別、mode、length、ID、許容窓、Seed、Auth Keyのどれかが合わなければ受信側は破棄する。

しかし、このAuth KeyはBFD Control packet全体のhashや要約を含まない。RFC 9986はパケット内容が完全には認証されないと明記する。一致によって分かるのは、共有秘密を知る真正な送信側だけがその継続信号を作れた、という範囲までである。

そのため低コスト形式は、セッションがすでにUpのときだけ使え、状態変化を通知できない。立ち上げ、状態遷移、定期的な強い再確認には、パケット完全性を調べる高コストmodeを使う。RFC 9985のこの役割分担は既存記事の題材であり、本稿の独自点ではない。本稿が追うのは、許された継続確認であっても、受信側の一方向状態を越えるときにrollback可能性が必要だという内部境界である。

BFDのUpも万能な到達性証明ではない。アプリケーションの応答、経路選択の正しさ、利用者からサービスまでの到達、特定payloadのend-to-end通過までは示さない。局所的な問いへの回答を、ネットワーク全体の保証に広げてはならない。

限界を隠さないExperimental RFC

RFC 9986はAshesh Mishra、Alan DeKok、Mahesh Jethanandani、Sonal Agarwal、Jeffrey Haasの共著である。Mishraは2017年の前身draft、RFC 9985、さらに古いBFD integrity-check最適化特許にも名を連ねる。長期的な関与を示す記録ではあるが、共同設計を単独発明へ置き換える根拠にはならない。

文書の位置づけはIETFのExperimentalであり、Internet Standardではない。Security ConsiderationsもISAACを一般解として扱わない。適切な暗号hardware accelerationを持たない装置という制約のために選ばれ、分析は限定的で、支援が利用できる環境では優位性がない。他のIETF protocolへ流用するには不適切だとまで述べている。

秘密鍵の配送は範囲外である。セッション中にAuth Key IDを変えて同期し直す手順はないため、key rotationにはセッションを管理上停止し、再seedする必要がある。強modeと軽modeで別鍵を使えば一つの漏えいの影響は抑えられるが、両端の設定不一致でmode切替直後に落ちる危険は増える。

共通仕様があるからといって、運用者の判断が消えるわけではない。仕様は最小の境界を決め、残る選択は実際の制御者へ返している。

合格だけでなく、不合格後を試験する

重要な試験は通常のページ内一致ではない。許容された損失窓には入るが、次ページ側を指す不正パケットを注入する。test harnessは非公開状態の一方向fingerprintを採り、誤ったAuth Keyを送り、checkpoint完了、mixing、不一致、元のfingerprintへの復元という順番を確認する。その直後に本来の正当パケットを送り、受理できることまで確かめる。

Seed、Key ID、mode、lengthの誤り、窓の内外、32ビットwraparoundでも繰り返す。checkpoint、mixing、restoreと通常のページ内処理にかかるmemoryと時間を測る。無効な未来パケットの連打でCPUや候補状態が際限なく増えないことも必要だ。

公開証跡にはbuild、session、ticket、秘密でないKey ID、窓、base/index、opaqueなcheckpoint指紋、時間、commitまたはrestoreの結果を置く。強認証の最終実施と、再起動を伴う鍵更新の演習も記録する。秘密を漏らさず、動作だけを立証する設計である。

権限を、実際の制御面より大きくしない

Lu Hengのagency原則に沿えば、役割は分かれる。著者は相互運用の不変条件を定める。実装者は全状態のコピー方法と保護を決める。運用者は鍵、強認証の周期、停止時刻を選ぶ。peerのrunning codeが個々の一致を決める。誰も他者の制御面まで保証できない。

最小初期仕様は「破壊前に保存し、失敗後に復元する」を固定するが、memory layoutの全てを統一しない。将来の局所判断を残しながら、試験可能な底線を作る。

そして最後はrunning codeである。RFCのMUSTは正しいbranchを記述するだけで、特定製品の稀なcross-page failure pathが本当に戻ることまでは証明しない。fault injection、前後指紋、続く正当パケットの受理が、その空白を埋める。

信用されていない入力が未来を尋ねただけで、検証器に正当な過去を不可逆に処分する力を与えてはならない。残し、試し、証明された後だけ進む。それが高速化を壊れにくくする最小の作法だ。

出典