要点

  • IPv4 のタイプ68は、参加するシステムが時刻、またはアドレスと時刻の組を追記する有限の記録欄だった。
  • ホストとルーターの要件は協調を残したが、認証の欠如、時計のずれ、情報露出、広範なフィルタリングが実用性を狭めた。

送信者が用意し、経路が書き込む

RFC 791 の Internet Timestamp は、送信時に完成している値ではない。タイプ68として予約された領域を、パケットを処理するシステムが順番に更新する。copy bit は0なので、フラグメント化されても最初のフラグメントにしか残らない。また、一つのデータグラムに置けるのは一度だけだった。

形式は書き込みの限界を明示した。長さは最大40オクテット。ポインターは次の空き位置を示し、最小の正しい値は5である。続く制御部分では、4ビットのオーバーフローカウンターと4ビットのフラグを共有した。空きがなければ、機器は欄外へ書かずにカウンターを増やす。そのカウンターまであふれた場合、あるいは長さやポインターが不正な場合、データグラムは誤りとして破棄され、ICMP Parameter Problem を返すことができた。

フラグは観測の形を変えた。0なら32ビットのタイムスタンプを順に記録する。1なら各機器が自分のインターネットアドレスを先に置き、その後に時刻を置く。3ではアドレスをあらかじめ並べ、次のアドレスが処理中のシステムに一致するときだけ時刻を書く。標準値は世界時の午前0時からのミリ秒である。それを得られない場合、別の時間基準も使えるが、最上位ビットを立てて非標準値だと示さなければならない。

ここから読み取れるのは、全経路の監査記録ではなく、限られた参加の痕跡である。40オクテットでは長い経路を収められず、アドレス併記ならさらに早く尽きる。記入者の本人性は認証されず、沈黙したホップが要求を受けたかどうかも分からない。日付もなく、各時計が同期している保証もない。

実装要件が示した温度差

RFC 1122 は、ホストによる生成と処理をどちらも任意とした。ただし実装するなら、生成元はモードが許す場合に自分の時刻を記録し、宛先は可能なら上位層へ渡す前に現在時刻を加える。時刻値は ICMP の規則に従い、世界時午前0時からのミリ秒を優先し、正しい値を出せないときは非標準の印を付ける。

RFC 1812 は転送するルーターにサポートを求めた。フラグ3では、次の指定アドレスがルーターのどれか一つのアドレスと一致すればよく、入口または出口インターフェースである必要はない。フラグ0と1を更新せず通過させるスイッチを実装してもよいが、初期状態は無効でなければならない。一方で同文書は、到着に近い時点で書くほど役立つものの、時計が同期していなければ価値が落ちるとも述べた。

診断情報が攻撃者にも読めるとき

RFC 7126 は、処理時間とアドレスが障害調査に役立つ一方、トポロジー、システム時刻、実装の特徴を漏らすと整理した。時計のずれから物理機器を見分けられる可能性まである。経路を可視化する欄は、望まない観測者にとっても情報源だった。

さらに、IPv4 オプションを落とす境界が一つでもあれば診断は成立しない。通常の ping はオプションなしで動く。RFC 7126 は、広範な破棄によって Timestamp を使う手法はすでに事実上利用不能だとし、ルーター、セキュリティゲートウェイ、ファイアウォールに破棄を勧告した。

出典