要約

  • インターリーブモードは、前の応答のより正確な送信タイムスタンプを後の応答で返すため、一つの測定が複数交換にまたがる状態へ依存する。
  • RFC 9769 は一意性、一回限りの照合、モード判定、基本モードへの復帰を求め、精密な値が別のパケット履歴へ接続されることを防ぐ。
  • Origin の一致は相手の認証でも遅延攻撃への耐性でもなく、サンプル採用、時計補正、業務上の効果を証明しない。

NIC が実際の送信時刻を刻んだ瞬間、そのパケットはもうアプリケーションの手を離れている。ユーザー空間が事前に書いた値より正確でも、元のパケットへ戻して書き直すことはできない。

RFC 9769 の答えは、次のパケットに載せることだ。前回の送信を後から報告する。追加の補正パケットも新しい拡張フィールドも使わない。その代わり、数値の正しさは「どの前回を指しているか」という状態の連続性に預けられる。

精度が上がっただけではない。来歴を失ったときに何を言わないかまで、プロトコルの責任になった。

遅れて確定する送信時刻

基本的な NTPv4 は、クライアント送信、サーバー受信、サーバー送信、クライアント受信という四つの時刻からオフセットと往復遅延を推定する。サーバー送信時刻をユーザー空間で入れると、その後のシステムコール、待ち行列、ドライバー、ハードウェアの遅れが残る。物理層に近いタイムスタンプほど正確だが、送信後にしかプロセスへ戻らない。

訂正専用の二つ目のパケットは増幅や長さの非対称を招く。そこでインターリーブは、次回の応答に前回答の実送信時刻を入れる。NTP ヘッダーは変えず、Origin、Receive、Transmit の関係だけを変える。

これは Heng Lu のいう最小初期仕様に近い。共通層は再現可能な観測だけを増やす。相手の身元、経路の安全性、採用する時刻源、時計を動かす判断までは共有権限にしない。

Origin は記憶を引く取っ手になる

基本モードでは、サーバー応答の Origin が今回のクライアント要求の送信時刻を返す。クライアントの保存値と一致しなければ bogus と判定される。

インターリーブモードでは、クライアントが前回の有効応答にあったサーバー受信時刻を、次の要求の Origin に入れる。サーバーは保存済みの受信・送信ペアからその値を探し、対応する前回答の正確な送信時刻を返す。

Origin はサーバー記憶への索引であり、本人確認書類ではない。RFC は IP アドレス単位で状態を分けることを許すが、ポート単位にはしないよう勧める。RFC 9109 が要求ごとの UDP ポート乱数化を認めるからだ。NAT や共有アドレスも含め、ネットワーク座標を恒久的な主体へ読み替えることはできない。

一致が示すのは、提示値が保存レコードにあったという限定的な事実だ。誰が提示したか、参加資格があるかは別の証拠を要する。

一意性が履歴の混線を防ぐ

二つの応答が同じ受信タイムスタンプを持てば、後の要求は二つの履歴を区別できない。サーバーが別回答の送信時刻を返し、クライアントが異なる交換を一つの測定へ縫い合わせるおそれがある。

RFC 9769 は受信・送信値に十分な一意性を求め、両者が等しいパケットを送ってはならないとする。時計の分解能で区別できないときは、NTP の最小小数単位、約四分の一ナノ秒だけ片方を進めてもよい。

これは物理時刻を新たに観測したのではない。クロックの有効精度より下で識別空間を守る操作である。同じ欄が時刻と相関トークンを兼ねる以上、監査は値の由来と調整理由を分けて記録しなければならない。

一致した受信時刻は再利用もできない。インターリーブ応答に使ったら消費し、別要求の認定に回さない。一つの過去から複数の整合しない系譜を作らないためだ。

状態がなければ、基本モードへ戻る

最初の交換は必ず基本モードになる。前提となる履歴がまだないからだ。サーバーはメモリを抑えるため古いペアを捨てられる。パケット損失後も必要なペアが残っていれば回復できるが、消えた場合に近似値や似た相手を選んではならない。応答するなら基本モードに戻り、新しい状態を次回用に保存する。

この復帰は精度の敗北ではなく、主張範囲の管理である。系譜のない高精度値より、来歴のある低精度値の方が正しい。「ハードウェア時刻」という集計でモード復帰を隠せば、RFC が守った境界を運用が壊す。

保存領域は可用性攻撃の対象にもなる。大量要求、送信元詐称、認証済み要求の再送によって有用なペアを追い出せる。クライアントはサーバーが常にインターリーブ応答できると仮定してはならない。基本モードは単なる古い互換機能ではなく、安全な退路である。

二つの有効応答で一つの鎖が閉じる

基本モードは一往復で測定できる。インターリーブでは後の応答が前回答の正確な時刻を持つため、連続する二つの有効応答が必要になる。その間、クライアントは未完了状態を保護しなければならない。無効な応答で上書きすると、次の正しい応答を受けても鎖を閉じられない。

運用記録には最終オフセットだけでなく、前後パケットのハッシュ、アソシエーション、判定モード、Origin の一致、ペアの年齢と消費、損失、退避理由、使用した四時刻集合が必要になる。

RFC は二つの集合を認める。遅延でフィルターするクライアントに推奨される集合は前の交換を測る。もう一つは現在に近いオフセットを得る一方、区間が長くなるため両時計の周波数差が遅延値へ強く影響する。新しさと安定性は別の目的であり、採用責任は消費側にある。

対称とブロードキャストでは条件が変わる

対称モードの双方は異なる周期で送信できる。応答が一つ欠けるだけで、遠隔送信時刻と誤ったローカル受信時刻が組になる。RFC は送信順を厳しく制限し、アクティブ側で明示設定されるまでインターリーブを無効にするよう勧める。

ブロードキャストでは、今回の概算送信時刻に加え、前回の正確な送信時刻を Origin に載せる。対応クライアントは直前パケットと比較し、差が上限を超えればインターリーブ同期に使わない。経路遅延が必要なら、ブロードキャストだけでは足りず、クライアント/サーバー交換が要る。

したがって「対応済み」という一つのフラグだけでは測定を説明できない。モード、順序、前提状態を同時に示す必要がある。

相関は認証でも遅延対策でもない

予測しにくい Origin はオフパス攻撃者の盲目的な偽造を難しくする。RFC 9769 は受信時刻を他の相手へ漏らさず、要求時刻の全ビットを乱数化するよう勧める。RFC 8633 は Origin 不一致を監視対象にし、制御問い合わせが期待値を漏らし得ると警告する。NTP データグラムの一次研究は、予測可能なクライアント状態が攻撃へ変わる過程を示す。

それでも相関値は暗号学的身元ではない。NTS は交換を認証できるが、内容を変えず一方向だけ遅らせるオンパス攻撃までは消さない。RFC 7384 は遅延攻撃を独立した要件とし、RFC 8915 も複数の時刻源や経路を部分的な緩和策として残す。

解析、状態照合、一意性、認証、経路評価、源選択、時計制御、アプリケーション結果は別々の現実層である。前段の成功を後段の受領書にしてはならない。

桁数ではなく来歴が精度を支える

細かな数字ほど権威的に見える。しかし RFC 9769 が価値を持つのは、数字を増やしたからではなく、その数字を正しい交換へ結ぶ条件を明示したからだ。

実行コード優先の立場では、実際に使われたモード、発見した状態ペア、認証した相手、選択を通ったサンプル、時計に加えた操作、依存アプリケーションの結果を別々に確かめる。RFC は仕組みを公開する。現実の到達を示すのは運用証跡だけである。

出典

  1. RFC 9769 — NTP Interleaved Modes
  2. RFC 5905 — Network Time Protocol Version 4
  3. RFC 9109 — NTPv4 Port Randomization
  4. RFC 7384 — Security Requirements of Time Protocols
  5. RFC 8633 — Network Time Protocol Best Current Practices
  6. RFC 8915 — Network Time Security for NTP
  7. The Security of NTP's Datagram Protocol
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile