要約
- RFC 10030はNTPのクライアント/サーバーおよび対称モードを単一宛先のPTPイベントメッセージに格納し、PTP専用のNIC時刻印と対応する透過クロック補正を利用できるようにした。
- 補正値は認証できず、負の補正結果は拒否され、root delayは補正されない。NTS、複数時刻源の選択、誤差の評価は引き続きNTP側の仕事である。
ポート変更が示す設計の境界
NICのハードウェア時刻印能力には上限がある。高速回線の全フレームを対象にできない機器では、PTPの種類やポートだけを認識するフィルターが使われる。通常のNTPがUDP 123で届いても、その機器は適切な位置で受信時刻を取得できないことがある。
RFC 10030はNTPをPTPに置き換えない。NTPメッセージを組織固有TLVに入れ、単一宛先のPTPイベントメッセージで運ぶ。対象はクライアント、サーバー、対称モードであり、NTPブロードキャストは対象外だ。IANAのOUI 00-00-5Eの下で、subtype 0x1がNetwork Time Protocol Messageとして登録された。
要求をPTP経由で受けたサーバーは、応答も同じ経路で返さなければならない。増幅を避けるため応答は要求より長くできない。長い応答が想定されるなら要求側がパディングする。同期に用いる応答は、経路全体がPTPに対応していない場合の非対称遅延を抑えるため、要求と同じ長さが望ましい。
319番ポートで得るもの、失うもの
UDPを使う場合、送信元と宛先にはPTPイベント用の319番ポートが推奨される。NICのフィルターが一致し、ハードウェア受信時刻印を得やすくなるからだ。しかしRFC 9109のNTP送信元ポート無作為化を使えば、319だけを見るフィルターから外れる。
これは隠された副作用ではない。仕様が交換条件を正面から示している。NTSは内側のNTP交換で引き続き利用できるが、外側のPTPヘッダーまで認証するわけではない。精度が上がることと攻撃面が一律に縮小することは同義ではない。
PTP 2.1ではdomainNumberとsdoIdも確認する。既定の推奨はdomain 123、sdoId 0で、衝突する場合は変更できる。ただし通信する参加者全員が同じ組を使う必要がある。この確認はメッセージの範囲を決めるもので、時刻源の正しさを証明するものではない。
補正値を信用せずに使う
one-step E2E透過クロックは、PTPイベントが通過した際の転送遅延をcorrection fieldに加える。NTPクライアントが往復測定を補正するには要求側と応答側の両方が必要だ。応答側はPTPヘッダーにあり、要求側は新しいNTP Network Correction拡張フィールド、型0x010Aでサーバーから返される。
サーバーは要求に書かれた補正値を無視しなければならない。クライアントは要求時にゼロを置く。両方向の値がそろえば、受信時間や透過クロックの周波数誤差も考慮し、peer delayとoffsetを修正できる。
ただし、補正後の遅延、要求補正、応答補正のいずれかが負なら同期に使えない。root delayは補正してはならず、最大想定誤差であるroot distanceをネットワーク補正から独立させる。測定値だけが都合よく改善し、誤差上限まで縮むことを防いでいる。
透過クロックの補正は認証できない。経路上の攻撃者は値を変更できる。受け入れ可能な補正を測定遅延より小さく制限することで影響を抑えるが、制限は署名ではない。RFCが述べるのは、未変更のNTPパケットを遅らせる攻撃と同程度に影響を閉じ込めることだ。
選ぶ主体はNTPクライアントのまま
より正確な到着時刻は有用な証拠である。しかし、NTPは複数サーバーを比較し、故障した源を外し、サンプルを選別し、root distanceを保つ。PTPの輸送層はその判断材料を改善しても、判断そのものを交換機やNICへ移さない。
一台のホストが、あるPTP domainではPTPによって同期し、別のdomainではNTPを運ぶだけという構成も可能だ。経路上に他のPTPクロックが必須でもない。対応する透過クロックがあれば補正を使い、なければNIC時刻印だけを利用できる。
この分離はrunning codeを壊さない。既存NTPの選択、認証、誤差計算を残し、使える現場だけが薄い新輸送層を採用する。最初の仕様を小さく保つことで、将来の導入判断を各運用者に残した。
情報源
- IETF Datatracker — NTP Over PTP
- IETF Datatracker — 文書履歴
- IETF Datatracker — shepherd write-up
- Lu Heng — Minimum Initial Specification
- Lu Heng — Running-Code Primacy
- IETF Mail Archive — RFC 10030公表
- IANA — OUI Ethernet Numbers
- IANA — NTP Parameters
- RFC Editor — RFC 10030の状況
- RFC 10030 — NTP over PTP
- RFC 5905 — NTPv4
- RFC 7822 — NTPv4拡張フィールド
- RFC 8126 — IANA登録方針
- RFC 8915 — Network Time Security
- RFC 9109 — NTPポート無作為化
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
