要約

  • NTPは四つのタイムスタンプからオフセットと往復遅延を推定し、繰り返し観測を濾過・比較してからクライアント自身の時計を調整する。一回の応答は真実ではない。
  • stratumは基準時計までの同期距離を示し、ループを防ぐための値である。精度、所有権、制度上の序列を保証せず、複数サーバーが同じ障害に依存することもある。
  • NTSが認証するのはクライアントとサーバーの通信であり、上流時刻の正しさではない。多様性、利用許可、監視、最終的な時計制御は運用者に残る。

接続された時計が二週間ずれていた

RFC 1129は1989年、94,260台のホストとゲートウェイに三つの時刻プロトコルで問い合わせた調査を報告した。応答した20,758台のうち、約半数は基準から二分以上、約一割は四時間以上ずれていた。二週間を超える誤差もあった。

これは全インターネットの国勢調査ではなく、その方法に応答した機器の結果である。それでも、到達可能性と正確さが別物であることは明白だった。誤った時計も規則正しく返答し、高い桁数を表示できる。

NTPは絶対に正しい一台を任命しなかった。異なる証言を測定可能にし、クライアントが疑わしい証言を採用しない仕組みを作った。

不確かな往復を四つの時刻で囲む

1981年のDCNET Internet Clock Serviceはすでに原型を示していた。RFC 778には、COMSATのWWV電波時計と、オフセットやドリフトを持つ電源周波数時計が登場する。ICMPタイムスタンプで要求と応答の時刻を記録した。

現在の表記では、クライアント送信がt1、サーバー受信がt2、サーバー送信がt3、クライアント受信がt4である。オフセットは[(t2 - t1) + (t3 - t4)] / 2、往復遅延は(t4 - t1) - (t3 - t2)で推定する。

往路と復路の一方向遅延を別々に観測してはいない。経路が非対称なら、その差が時計誤差に混ざる。細かな数値表示は、輸送経路の不確かさを消さない。

パケットを失っても、次の観測がある

RFC 958は1985年9月に最初のNTPを規定した。1988年のRFC 1059は、約二年の試験運用後のVersion 1を説明する。複数の一次基準源と、自己組織化する階層的な二次サーバー網があり、世界で一台のマスターを選挙する必要はなかった。

時刻データグラムが失われても、必ず再送して取引を完成させる必要はない。次の観測で更新できた。複数ゲートウェイを通り、遅延も経路も変わる当時のインターネットに適した性質だった。

初期版にも標本濾過、異常値抑制、発振器ドリフト補償、段階的な時刻修正があった。RFC 1059の数十ミリ秒という結果は、その試験環境に限定された報告であり、後世の全ネットワークへの保証ではない。

選別は多数決でも予言でもない

各情報源からはオフセット、遅延、不確かさの系列が得られる。フィルターは一時的な待ち行列に時計を支配させないよう、特に見かけの遅延が小さい有用な標本を重視する。

情報源同士が矛盾すると、選択処理は推定値を誤差区間として比較する。十分な共通区間から外れる候補はfalsetickerとして除外される。RFC 1305はNTPv3で濾過と選択を洗練し、RFC 5905はNTPv4で選択、クラスタリング、残った情報源の結合を記述した。

University of Delawareのアルゴリズムは、十分な交差がなければ選択に失敗することも明記する。「非同期」は、対立を精密な数字に偽装するより正しい結論になりうる。

さらに、台数は独立性ではない。別々の名前やネットワークが同じGPS受信機、仮想基盤、運用者、leap smear方針に依存している場合、同じ方向へ誤る。タイムスタンプだけでは隠れた依存関係をすべて発見できない。

stratumは玉座ではない

NTPv4でstratum 1は一次基準時計に直接結びつく。2から15は同期チェーン上の距離、16は非同期を表す。この距離は、自分の下流から時刻を受け取って誤差を循環させるループを防ぐ。

小さい数字は品質証明ではない。混雑し監視されていないstratum 1より、安定したstratum 3の方が良いことはありうる。所有権や公的権限も示さない。NTPには階層と一次基準がある一方、クライアント／サーバー、ブロードキャスト、対称ピアの各モードがある。単一頂点のピラミッドでも、信頼不要の平面でもない。

技術上の距離を政治的な順位に読み替えないことが、設計の境界である。

算術の外側にある運用

RFC 8633は、実際に独立した複数情報源と継続監視を勧める。四つ以上が役立つのは障害が独立している場合だ。異なるASのサーバーが同じ基準時計を共有することも、leap smearを使う時刻と通常のUTCが閏秒付近で意図的に食い違うこともある。

利用許可も必要である。第三者の公開サーバーを何百万台もの製品に無断で固定すれば、製品寿命のあいだ通信費と防御費を押しつける。UDPサービスの公開範囲、レート制限、増幅攻撃への監視も運用品質の一部だ。

通信の真正性は、時刻の真正性ではない

RFC 8915は2020年、クライアント／サーバーモード向けのNetwork Time Securityを標準化した。TLSを使うNTS-KEで鍵材料と保護cookieを作り、その後のNTP拡張フィールドを認証する。サーバーは設定後に状態を保持せず、cookieをクライアントに持たせられる。

NTSは期待したサーバーから来たか、途中で改変されたかを検証する。上流基準の正しさや独立性は証明しない。認証された誤りも誤りである。対称モードと制御モードもRFC 8915の対象外だ。

共有時刻を、反証できる証拠として保つ

ログ、証明書、データベース、産業制御は出来事の順序を時刻に委ねる。だからこそ、有名な一サービスを確実性の代用品にしたくなる。NTPはより厳しい方法を選ぶ。複数の不完全な証言を集め、経路を割り引き、矛盾を排除し、残りを組み合わせ、ローカル発振器を自ら制御する。

信頼は消えず、複数化され、観測され、撤回可能になる。基準時計、サーバー、ネットワーク、クライアントはそれぞれ異なる責任を持ち、どの層も他の層の権利を自動的に得ない。不一致を扱う仕組みが、一台を恒久的な主権者にせず共通時刻を可能にした。

情報源と証拠の限界

前史はRFC 778、最初の仕様はRFC 958、Version 1はRFC 1059、1989年調査はRFC 1129による。NTPv3はRFC 1305。成熟したモデルはRFC 5905とClock Select Algorithm、運用指針はRFC 8633、NTSの範囲はRFC 8915に基づく。

調査値は回答機器についての値である。後期版の機能を1985年の実装へ遡及させてはいない。