要約

  • Kiss-o'-DeathはStratum 0のNTP応答でReference Identifierを状態コードとして使い、拒否やレート超過を知らせた。その受信・送信timestampは時刻証拠ではなく、破棄しなければならない。
  • クライアントは応答を未処理の要求に結び付けた後、コードごとの限定された処理だけを行う。多くのKoDが未認証だったため、従順さそのものがサービス拒否の入口にもなった。

1秒ごとの問い合わせが空白の意味を変えた

RFC 4330は、家庭・オフィス用ルーターが特定の大学時刻サーバーを参照するよう大量に設定され、あるエラー条件で相当数が1秒間隔の送信を始めた事例を記している。トラフィックの急増は激しく、原因究明と抑制には極端な対応が必要になった。

サーバーはパケットを捨てられる。しかし損失と拒否はクライアントから見れば同じ沈黙になりやすい。実装によってはタイムアウトが再送を促し、保護のための廃棄が新しい負荷を呼ぶ。協調できる相手には、理由と期待する行動を小さく返す必要があった。

その場所は既存ヘッダーの中にあった。RFC 1305はStratum 0をunspecifiedとしたが、この状態のReference Identifierに状態通知の役割を与えていなかった。RFC 4330はStratum 0を負の応答に使い、4バイトのReference IDへASCIIのkiss codeを置いた。この形式がKiss-o'-Death、KoDである。

新しいポートや制御セッションは要らなかった。要求に戻る経路をそのまま使いながら、通常の時刻応答とは別の意味を持たせた。

同じ形でも測定値ではない

通常のNTP応答では、サーバーのReceive TimestampとTransmit Timestampが、クライアント側の送受信時刻と組み合わされ、offsetとround-trip delayの推定に使われる。KoDは外形を共有するが、その証拠能力を失っている。

RFC 5905は、Stratum 0をunspecifiedまたはinvalidとし、その場合にReference Identifierが状態やアクセス制御を伝えられると定める。サーバーが置くReceive/Transmit Timestampは未定義であり、信頼してはならず、破棄しなければならない。

したがってKoDは「精度の悪い時刻サンプル」ではない。clock filterやsource selectionに入れる前に、入力の種類そのものを変える必要がある。読み取るべきものは4文字の負の制御であり、周囲の時刻らしい数値ではない。

応答はまず要求に戻される

クライアント／サーバーモードでは、応答のOrigin Timestampが要求のTransmit Timestampを反映する。RFC 5905は、この一致を偽造やreplayの検出に使う。RFC 8633はKoDについて、Origin Timestampが有効な場合にだけ受け入れなければならないとする。

処理の順番は重要だ。まず未処理要求との対応を確認する。次にStratum 0とコードを認識し、未定義のtimestampを時刻処理から除外する。最後に、そのコードに割り当てられたローカルな状態変更だけを認める。

Origin Timestampの一致は暗号学的な身元証明ではない。任意のUDPパケットより強い結び付きは与えるが、観測可能な状態を知る攻撃者や経路上の相手まで排除するわけではない。「自分の要求への応答」と「主張が真実」は別である。

DENYとRATEは違う権限を持つ

DENYは遠隔サーバーによるアクセス拒否、RSTRはローカルポリシーによる制限を表す。RFC 5905はどちらについても、そのサーバーとのassociationをdemobilizeし、送信を止めるよう求める。RATEは要求頻度が閾値を超えた状態であり、クライアントは直ちにpolling rateを下げ、繰り返し受け取ればさらに下げる。

DENY/RSTRは関係を閉じる。RATEは将来の計測可能性を残す。いずれも時計を修正する権限は持たない。Xで始まる値は私用・実験用に予約され、未知のコードを一般的な遠隔命令として扱う根拠もない。

現在のIANA NTP ParametersにはDENY、RSTR、RATE、後のNTSNなどが登録されている。登録は同じバイト列を同じ説明へ結び付けるが、到着したパケットの真正性や、主張された状態の正しさまでは保証しない。

後退量をサーバーだけに決めさせない

RFC 8633はKoDを尊重するよう勧告し、設定画面を持たない組み込み機器では特に重要だとする。RATEを受けたクライアントは合理的な上限までpoll intervalを広げるべきで、poll exponent 13、すなわち2時間を超えないことが示されている。

同時に、サーバーが送ったpoll値を無条件に採用してはならない。極端に大きい値はクライアントを実質的に沈黙させ、サービス拒否を成立させる。サーバー負荷を減らす要求と、クライアントが時刻を失わない条件は一致するとは限らない。

KoDはクライアントの正しい実装にも依存する。RATEを無視するものや、誤って送信量を増やすものがあれば、サーバーはdrop、rate limit、監視といったプロトコル外の防御を必要とする。協調信号は最後の防壁ではない。

NTSNは例外を認証の文脈へ戻した

RFC 8915のNetwork Time Securityでは、保護された応答が未処理要求と同じUnique Identifierを持ち、対応するserver-to-client鍵で認証されなければならない。どちらかに失敗すれば、それ以上処理せず破棄する。

サーバーがcookieを検証できない、または要求を認証できない場合、NTSNというKoDを返せる。これはNTS negative acknowledgmentであり、保護状態を回復できなかったため、通常のNTS CookieやAuthenticator fieldを含まない。

それでも自由な解除命令にはならない。過去に認証済みNTS応答を返したサーバーからのKoDは、未処理要求と一致するUnique Identifierを含まなければ破棄される。強制的なassociation解除後にNTS-KEをやり直す場合も、再試行をrate limitして新たなループを防ぐ。保護されていないNTPへの自動downgradeも認められない。

NTSは「どの要求に属するか」を強めたが、KoDを時刻証拠には変えなかった。

登録表が決められるのは語彙まで

RFC 5905はReference IdentifierとKoD codeのIANA登録表を作った。RFC 9748は登録方針をSpecification Requiredへ変更し、新しいASCII値を大文字・数字と右側ゼロ埋めに限定し、X接頭辞を実験用に予約した。3人のdesignated expertsのうち2人の承認が変更に必要となる。

4バイトは短いが、その意味は長く残る。公開仕様と専門家審査は、独立した実装が同じコードで矛盾した動作をする危険を減らす。しかし登録表は、実際のパケットを認証せず、クライアントの安全な上限も選ばない。

KoDがインターネットへ持ち込んだのは、完全な命令ではなく、分割された拒否権だった。サーバーは条件を示す。要求状態が帰属を決める。コードが狭い反応を定める。クライアントが上限と回復を保持する。時刻を示さない時刻パケットは、沈黙より多くを伝えながら、時計そのものを支配しないことで役に立った。

出典と限界

初期の空白はRFC 1305、運用事例と明示的KoDはRFC 4330による。コード別動作とtimestamp破棄はRFC 5905、運用上限はRFC 8633、NTSはRFC 8915、登録方針はRFC 9748とIANAによる。2026年の導入率、準拠率、攻撃頻度は示さない。