要約

  • Kiss-o’-Deathではstratum 0が時刻標本としての利用を否定し、4文字のコードがDENY、RSTR、RATEなどの状態を示す。受信・送信タイムスタンプは未定義で、時計計算には使えない。
  • サーバーは助言を送れても遠隔クライアントを強制できない。要求との照合、正しいポーリング変更、ローカル上限、非協力的な送信元を止めるフィルターが別々に必要だった。

プロトコルの受信処理を、単純な「成功」と「失敗」に分けると見落とすものがある。NTPのKiss-o’-Death（KoD）は、構文としては応答でありながら、時刻標本としては明確な不採用だった。受け取った瞬間に時計を直すのではなく、クライアントはサーバーとの関連をどう変えるか判断する。

この二段階は偶然できたものではない。古いパケット形式に存在した余白が、運用事故を経て限定的な制御語彙へ変わった。

古い四オクテットには、まだ命令がなかった

1992年のRFC 1305は、NTPv3のStratumを8ビット、Reference Identifierを4オクテットとした。stratum 0は未指定であり、stratum 0と1ではReference Identifierを4文字のASCIIとして表した。1996年のRFC 2030も、初期SNTPv4でその形を引き継いだ。

しかし、これはKoDが1992年から存在したという意味ではない。格納場所と共有された意味は別物である。stratum 0のReference Identifierが拒否やレート制御として明文化されたのは、2006年のRFC 4330だった。

同RFCは背景となる出来事も記録している。多数の家庭・オフィス用ルーターが一つの大学の時刻サーバーを参照するよう設定され、一部は毎秒問い合わせた。製品台数の増加とともにトラフィックは劇的に増え、運用者は極端な防御を迫られた。

工場で一度選んだデフォルトが、他者の設備に長期間の負担を作った。サーバーは各機器の設定を直せず、利用者は宛先さえ知らないかもしれない。単なるパケット破棄では、協力できるクライアントに理由が伝わらない。KoDは、その理由だけを既存の応答経路に載せた。

stratum 0は標本を弱めるのではなく、捨てる

RFC 5905のNTPv4では、stratum 0の応答は同期用として無効で、Reference Identifierをkiss codeとして解釈する。KoDのReceive TimestampとTransmit Timestampは未定義であり、破棄しなければならない。

したがって、KoDを「精度の低い時刻源」として候補集合に残してはいけない。offsetやdelayを計算する材料はない。通常応答が時刻についての観測を運ぶのに対し、KoDは次の相互作用についての状態を運ぶ。

DENYとRSTRなら関連を解除し、そのサーバーへの送信を止める。RATEならポーリング間隔を長くして送信を減らす。RFC 4330のINITやSTEPは一時的なサーバー状態を示す。短い名前が便利でも、その名前から一般的な権限を推測してはならない。DENYはポリシーの正当性を証明せず、RATEはクライアントの将来を無期限に予約しない。

一語の向きが状態機械を反転させた

RFC 5905の公開文には、RATEを受けたクライアントがポーリング間隔を「減らす」という誤記があった。間隔を短くすれば問い合わせは増える。検証済みErrata 3007は、正しく「増やす」へ修正した。

ここでは、仕様書を引用したという事実より、実行後の因果が重要になる。RATE受信後に次のパケットが遅くなり、サーバー負荷が下がるなら、ループは意図した方向に閉じている。速くなれば、ラベルを認識していても実装は保護機構を増幅器に変えた。

KoDはサーバーだけでは完成しない。クライアントがコードを知らなければ無視される。誤って実装すれば逆効果になる。応答は遠隔プロセス内の分岐を強制できない。

Origin Timestampは「いまの返答」を示す

RFC 8633は、Origin Timestampが有効なKoDだけを受け入れるよう求める。応答の値が、クライアントが保持する未処理要求に対応していなければならない。古い応答や無関係な注入は、関連状態を変える根拠にならない。

ただし照合は認証ではない。「自分がいま尋ねている問いへの返事らしい」と判断できても、「正当なサーバーが書いた」とは限らない。暗号保護がなければ、要求の材料を観測または推測できる攻撃者が、もっともらしいKoDを偽造する余地がある。

被害に偽時刻は不要だ。偽のDENYやRSTRは有効な時刻源を関連から外す。偽のRATEは次の観測を遅らせる。攻撃者は時計値ではなく、証拠を取りに行く頻度と相手を操作する。

運用記録も段階を分ける必要がある。受信、未処理要求との一致、認証、受諾、関連解除またはpoll変更は同じ出来事ではない。画面に「KoD」とだけ残せば、4文字に実際以上の証明力を与える。

ローカル上限が無期限の委任を防いだ

RATEを正しく尊重しても、サーバーの提案値を無制限に採用してよいわけではない。巨大なpoll値を受け入れると、故障または偽造応答によって長時間問い合わせを止められる。RFC 8633は、妥当な最大値としてpoll指数13以下、約2時間を挙げる。

この上限は、負荷を知るサーバーと継続性を守るクライアントの境界である。サーバーは圧力を知らせる。クライアントは、どこまで後退できるかを決める。

協力しないクライアントへの対策も別に残る。RFC 8633はKoDを無視または誤実装する例を前提に、サーバー側のパケット破棄を必要とする。フィルター、キュー保護、容量制御は、丁寧な応答の代用品ではなく独立した強制面である。

NTSNは認証不能時だけの細い出口だった

Network Time Securityを使うと通常応答を保護できる。しかし、サーバーがクライアントのcookieやauthenticatorを検証できなくなった場合、失敗を説明する通常の認証済み応答そのものを生成できない。

RFC 8915は、この場合のNTSNを定義する。サーバーはNTS CookieとNTS Authenticator and Encrypted Extension Fieldsを付けてはならない。以前に認証済み応答を受けていたクライアントは、未処理要求と一致するUnique Identifierを要求し、一致しなければ捨てる。

一致しても即座に高頻度の鍵交換を始めない。通常の次回pollまで待ち、有効な保護応答がなければNTS-KEをやり直す。その試行はレート制限し、新しい交換が成功するまで古いパラメーターでポーリングを続ける。

これは、未認証のメッセージを一般権限にせず、回復に必要な範囲へ閉じ込める設計である。NTSNを根拠に「KoDはNTSで認証される」と一般化してはいけない。

レジストリが揃えるのは意味であり、挙動ではない

RFC 5905はIANAのkiss codeレジストリを作った。2025年のRFC 9748は、最大4 ASCII文字、短い場合のゼロ埋め、実験用X、新規コードの大文字・数字、Specification Requiredによる審査を定めた。

レジストリは、別々の仕様が同じ短い名前を奪い合うのを防ぐ。だが、パケットを認証せず、製品適合性を証明せず、アクセス拒否を正当化しない。登録されたコードが実装されているか、受信後に何が起きたかは、稼働中のコードからしか分からない。

この分業がKoDの節度だった。IETFとIANAは共通語を管理する。サーバーは応答または破棄を選ぶ。クライアントは要求状態、上限、代替源を持つ。運用者は協力が破れたときのフィルターを持つ。中央の時刻レート管理者は作られなかった。

BTWの既存NTP史は、四つのタイムスタンプ、複数源の不一致、ローカル時計の規律を扱った。本稿はその計算を繰り返さない。時刻標本が意図的に欠けた応答から始め、短い助言がどこまで相手の状態を変えられるかを追う。