ネットワークタイムプロトコル

ネットワークタイムプロトコル（NTP）は、パケット交換方式の可変遅延データネットワーク上でコンピュータシステム間の時刻同期を行うためのネットワークプロトコルです。1985年以前から運用されているNTPは、現在も使用されているインターネットプロトコルの中で最も古いものの1つです。NTPは、デラウェア大学のデイビッド・L・ミルズによって設計されました。

NTP は、参加しているコンピュータを協定世界時(UTC)から数ミリ秒以内の精度で同期させることを目的としています。 ^{[ 1 ] : 3} NTPは、正確なタイム サーバーを選択するためにMarzullo アルゴリズムの修正版である交差アルゴリズムを使用し、ネットワーク遅延の変動の影響を軽減するように設計されています。NTP は通常、パブリックインターネット上で数十ミリ秒以内の精度で時間を維持でき、理想的な条件下ではローカル エリア ネットワークで 1 ミリ秒未満の精度を達成できます。非対称ルートやネットワークの混雑により、100ミリ秒以上の誤差が生じる可能性があります。 ^{[ 2 ] [ 3 ]} 

このプロトコルは通常クライアント・サーバーモデルで説明されますが、ピアツーピア関係でも同様に使用できます。ピアツーピア関係では、両方のピアが相手を潜在的な時刻ソースとみなします。^{[ 1 ] : 20}実装では、ユーザーデータグラムプロトコル(UDP)を使用してタイムスタンプを送受信します。サービスは通常ポート番号123 で動作し、一部のモードでは両側がこのポート番号を使用します。^{[ 4 ] [ 5 ] : 16}また、ブロードキャストまたはマルチキャストを使用することもできます。この場合、クライアントは最初のラウンドトリップのキャリブレーション交換の後、時刻の更新をパッシブに受信します。^{[ 3 ]} NTP は、迫りくるうるう秒の調整に関する警告を提供しますが、ローカルタイムゾーンや夏時間に関する情報は送信されません。^{[ 2 ] [ 3 ]}

現在のプロトコルはバージョン4（NTPv4）^{[ 5 ]}であり、バージョン3との下位互換性があります。^{[ 6 ]}

一般的なNTPクライアントは、1つ以上のNTPサーバーを定期的にポーリングします。クライアントは、時刻オフセットと往復遅延を計算する必要があります。時刻オフセットθは、2つのクロック間の絶対時刻の正または負（クライアント時刻 > サーバー時刻）の差です。これは次のように定義されます。

$${\displaystyle \theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},}$$ 往復遅延δは $${\displaystyle \delta ={(t_{3}-t_{0})-(t_{2}-t_{1})},}$$ どこ

• t ₀はクライアントによるリクエストパケット送信のタイムスタンプです。
• t ₁は、サーバーがリクエストパケットを受信した時のタイムスタンプです。
• t ₂は応答パケット送信時のサーバーのタイムスタンプであり、
• t ₃は、クライアントが応答パケットを受信した際のタイムスタンプです。^{[ 1 ] : 19}

オフセットの式を導出するには、要求パケットの場合、 $$t_0+θ+δ/2=t_1$$ 応答パケットについては、 $$t_3+θ - δ / 2 = t_2$$θ について解くと、時間オフセットの定義が得られる。

θとδの値はフィルタを通過し、統計分析（「緩和」）にかけられます。外れ値は破棄され、残りの3つの候補から時間オフセットの推定値が導き出されます。その後、クロック周波数が調整され、オフセットが徐々に減少します（「規律」） 。これによりフィードバックループが形成されます。^{[ 1 ]： 20}

クライアントとサーバー間の受信ルートと送信ルートの両方の公称遅延が対称である場合に、正確な同期が実現されます。ルートに共通の公称遅延がない場合、順方向と逆方向の移動時間の差の半分に相当する系統的なバイアスが存在します。非対称性を測定するために多くの手法が提案されていますが、^{[ 7 ]}実用的な実装の中では、chrony だけがその手法を取り入れているようです。^{[ 8 ] [ 9 ]}

1979年、ニューヨークで開催された全米コンピュータ会議において、大西洋横断衛星ネットワーク上で動作するインターネットサービスの、おそらく最初の公開デモンストレーションで、ネットワーク時刻同期技術が使用されました。この技術は後に1981年のインターネット技術ノート（IEN）173 ^{[ 21 ]}で説明され、そこからRFC 778に文書化された公開プロトコルが開発されました。この技術は、Helloルーティングプロトコルの一部としてローカルエリアネットワークに初めて導入され、ネットワークプロトタイピングに使用される実験的なオペレーティングシステムであるFuzzballルーターに実装され、そこで長年にわたって動作しました。 

当時も今も、関連するネットワークツールは他にもあります。イベントの時刻を記録するためのDaytimeおよびTimeプロトコル、 ICMP タイムスタンプメッセージ、および IP タイムスタンプ オプション ( RFC 781 ) などです。NTP のデータ分析やクロック同期アルゴリズムは備えていませんが、より完全な同期システムとしては、選挙アルゴリズムを使用してすべてのクライアントにサーバーを割り当てるUnixデーモンtimed ^{[ 22 ]}や、 NTP の階層モデルに似たサーバーの階層を使用するDigital Time Synchronization Service (DTSS) などがあります。 

1985年、NTPバージョン0（NTPv0）がFuzzballとUnixの両方に実装され、NTPパケットヘッダー、往復遅延、オフセットの計算方法（これらはNTPv4にも引き継がれている）がRFC 958に文書化された。当時利用可能だったコンピュータやネットワークは比較的低速であったにもかかわらず、大西洋を横断するリンクでは通常100ミリ秒以下の精度が得られ、イーサネットネットワークでは数十ミリ秒の精度が得られた。 

1988 年、関連アルゴリズムを含む NTPv1 プロトコルのより完全な仕様がRFC 1059で公開されました。これはRFC 956で文書化された実験結果とクロックフィルタアルゴリズムに基づいており、クライアント/サーバモードとピアツーピアモードを記述した最初のバージョンでした。1991 年、 David L. MillsによるIEEE Transactions on Communications の記事の公開により、NTPv1 のアーキテクチャ、プロトコル、およびアルゴリズムがより広範なエンジニアリングコミュニティの注目を集めました。^{[ 23 ]}  

1989年にRFC 1119が公開され、ステートマシンを用いてNTPv2が定義され、その動作を擬似コードで記述した。このRFCでは、管理プロトコルと暗号認証方式が導入され、これらはアルゴリズムの大部分とともにNTPv4にも引き継がれた。しかし、NTPv2の設計はDTSSコミュニティから形式的な正しさに欠けると批判され、クロック選択手順はNTPv3以降ではMarzulloのアルゴリズムを取り入れるように変更された。^{[ 24 ]} 

1992年、RFC 1305でNTPv3が定義されました。このRFCでは、基準クロックから最終クライアントに至るまでのすべてのエラー要因の分析が含まれており、複数の候補サーバー間で意見の相違が見られる場合に、最適なサーバーを選択するのに役立つ指標を算出できるようになりました。また、ブロードキャストモードが導入されました。 

その後数年間、新機能が追加され、アルゴリズムが改良されるにつれて、新しいプロトコル バージョンが必要であることが明らかになりました。^{[ 25 ]} 2010 年に、NTPv4 の仕様案を含むRFC 5905が公開されました。 ^{[ 26 ]}ミルズがデラウェア大学を退職した後、リファレンス実装は現在、ハーラン・ステンが率いるオープンソースプロジェクトとして維持されています。 ^{[ 27 ] [ 28 ]} IANA側では、ntp (ネットワーク タイムプロトコル) 作業グループが提案されたドラフトのレビューを担当しています。^{[ 29 ]} 

NTPv4以降、プロトコルは大幅に進歩した。^{[ 26 ]} 2022年現在プロトコルの更新を記述した 3 つの RFC 文書が公開されており、^{[ 18 ] [ 19 ] [ 20 ]}ネットワーク タイム セキュリティなどの多数の周辺標準^{[ 29 ]は含まれていません。 [ 30 ]}ミルズは自身のページで「NTPv5」の計画について言及していましたが、公開されることはありませんでした。^{[ 26 ]} chronyの M. Lichvar による「NTPv5」と呼ばれる無関係のドラフトが2020 年に開始され、セキュリティ、精度、スケーリングの変更が含まれています。^{[ 31 ]}

NTP が従来のタイム プロトコルに取って代わったものの、一部のユース ケースでは完全なプロトコルが複雑すぎると感じられました。1992 年に、このニッチを埋めるために、シンプル ネットワーク タイム プロトコル( SNTP ) が定義されました。SNTPv3 標準では、長期間にわたって状態を保存する必要がない NTPv3 の使用方法が規定されています。使用されるサーバーは 1 つだけなので、トポロジーは基本的にタイム プロトコルと同じになります。 ^{[ 13 ]} 1996 年に、SNTP は当時開発中だった NTPv4 のいくつかの機能を備えた SNTPv4 に更新されました。 ^{[ 15 ]} SNTPv4 は 2010 年に主要な NTPv4 標準に統合されました。^{[ 5 ]}

SNTP は新しいプロトコルを定義していないため、NTP と完全に相互運用可能です^{[ 32 ] : §14}。NTP と同じパケット形式とポートを使用するため、NTP サーバーとの互換性が確保されます。ただし、クライアント/サーバーには、ネットワークジッタのフィルタリング、クロック ドリフトの分析、複数の時間ソースの相互参照に必要な複雑なアルゴリズムがありません。そのため、完全な NTP アプリケーション スタックのオーバーヘッドなしに「十分な」時間が必要なIoTデバイスや基本的なハードウェアに適しています。 ^{[ 5 ]}

SNTPクライアントは通常、単一のサーバーに問い合わせて受信した時刻をローカルクロックに直接適用することで動作します。しかし、単純なアルゴリズムでは精度が低い時刻しか得られないため、SNTPソースから時刻を同期することは推奨されません。ただし、RFC 5905では、完全なオンワイヤプロトコルの追加的な複雑さは最小限であるため、単純なクライアントであっても完全な実装が推奨されると指摘されています。^{[ 5 ]}

NTP は、階層的で半階層的な時刻ソースシステムを使用します。この階層の各レベルはストラタムと呼ばれ、最上位の基準クロックに対してゼロから始まる番号が割り当てられます。ストラタムnサーバーに同期されたサーバーは、ストラタムn + 1で動作します。この番号は基準クロックからの距離を表し、階層内の循環依存を防ぐために使用されます。ストラタムは必ずしも品質や信頼性を示すものではありません。ストラタム 2 の時刻ソースよりも高品質のストラタム 3 の時刻ソースが見つかることはよくあります。^{[ a ]}ストラタ 0、1、2、3 の簡単な説明を以下に示します。

層0

これらは、原子時計、GNSS（GPSを含む）やその他の電波時計、またはPTP同期時計などの高精度な時刻計測装置です。 ^{[ 33 ]}これらは、接続されたコンピュータで割り込みとタイムスタンプをトリガーする非常に正確な毎秒パルス信号を生成します。ストラタム0デバイスは、基準クロックとも呼ばれます。NTPサーバーは、自身をストラタム0として通知することはできません。NTPメッセージのストラタムフィールドが0に設定されている場合、それは未指定のストラタムを示します。^{[ 5 ] : 21}

地層１

これらは、接続されているストラタム 0 デバイスとシステム時刻が数マイクロ秒以内の精度で同期されているコンピュータです。ストラタム 1 サーバーは、健全性チェックとバックアップのために他のストラタム 1 サーバーとピアリングする場合があります。^{[ 34 ]}これらはプライマリ タイム サーバーとも呼ばれます。^{[ 2 ] [ 3 ]}

層2

これらは、ネットワークを介してストラタム1サーバーと同期しているコンピューターです。多くの場合、ストラタム2コンピューターは複数のストラタム1サーバーに問い合わせを行います。また、ストラタム2コンピューターは他のストラタム2コンピューターとピアリングすることで、ピアグループ内のすべてのデバイスに対してより安定した堅牢な時刻を提供することができます。

層3

これらは、ストラタム2のサーバーと同期しているコンピューターです。ピアリングとデータサンプリングにはストラタム2と同じアルゴリズムを使用し、ストラタム4のコンピューターのサーバーとして機能することもできます。

ストラタムの上限は15です。ストラタム16は、デバイスが同期されていないことを示すために使用されます。各コンピュータ上のNTPアルゴリズムは相互に作用してベルマン・フォード最短経路スパニングツリーを構築し、すべてのクライアントからストラタム1のサーバへの累積往復遅延を最小化します。^{[ 1 ] : 20}

ストラタムに加えて、このプロトコルは参照識別子（refid）によって各サーバーの同期ソースを識別することができる。

ストラタム 2 およびそれ以下のサーバーの場合、refid はアップストリーム タイム サーバーの IP アドレスをエンコードした形式です。 IPv4 の場合は、これは単に 32 ビット アドレスです。 IPv6 の場合は、ソース アドレスの MD5 ハッシュの最初の 32 ビットになります。 refid は、タイミング ループを第一段階で検出および防止するために使用されます。^{[ 5 ]}

refid フィールドは、kiss-o'-death (KoD) パケットの場合、サーバーが休めるようにクライアントにリクエストの送信を停止するように指示するステータス ワードで埋められます。^{[ 5 ]}例としては、INIT (初期化)、STEP (ステップ時間の変更)、RATE (クライアントのリクエストが速すぎる) などがあります。^{[ 38 ]}プログラムの出力では、ネットワーク切断を示す XFAC など、パケットで送信されないコードを使用してエラーを示す場合もあります。^{[ 35 ]}

IANAはrefidソース名とKoDコードのレジストリを維持している。非公式な割り当てがまだ存在する可能性がある。^{[ 39 ]}

閏秒イベントの当日、ntpd は設定ファイル、接続された参照クロック、またはリモートサーバーのいずれかから通知を受け取ります。イベント中は NTP クロックは実際に停止しますが、時間が厳密に増加しているように見える必要があるため、システム時刻を照会するプロセスは、イベントの順序を維持するために、システムをわずかに増加させます。負の閏秒が必要になった場合は、23:59:58、00:00:00 のシーケンスで削除され、23:59:59 はスキップされます。^{[ 67 ]}

リープスミアリングと呼ばれる別の実装では、UTC 時間の正午から正午までの 24 時間以内に閏秒を段階的に導入します。この実装は、Google (社内および公開 NTP サーバーの両方)、Amazon AWS、^{[ 68 ]}、および Facebook ^{[ 69 ]}で使用されています。chronyはsmoothtimeおよびleapsecmode構成で leap smear をサポートしていますが、leap smear は非標準であり、混在するとクライアントの計算が狂うため、このような使用は公開 NTP プールと混在させてはいけません。^{[ 70 ]}

システム時刻の調整は一般的に特権操作であるため、NTP コードの一部または全部は、そのコア機能をサポートするために何らかの特権で実行する必要があります。 NTP コードベースのリファレンス実装では、他のセキュリティ上の問題はほとんど特定されていませんが、任意のコード実行やサービス拒否攻撃など、2009 年に発生した問題は重大な懸念事項でした。^{[ 71 ] [ 72 ]}プロトコルは、その歴史を通じて改訂とレビューを受けてきました。リファレンス実装のコードベースは、数年にわたり複数のソースからセキュリティ監査を受けています。^{[ 73 ]}

スタックバッファオーバーフローの脆弱性が発見され、2014年に修正されました。^{[ 74 ]} Appleはこの脆弱性を非常に懸念し、初めて自動更新機能を使用しました。^{[ 75 ]}ルートユーザーの認証情報で実行されるリファレンス実装を使用するシステムでは、無制限のアクセスが可能になる可能性がありました。OpenNTPDなどの他の実装は、コードベースが小さく、特権分離などの他の緩和策を採用しているため、この欠陥の影響を受けません。^{[ 76 ]}

Linux FoundationのCore Infrastructure Initiativeのために実施された3つのNTP実装の2017年のセキュリティ監査では、セキュリティの観点から、NTP ^{[ 77 ] [ 78 ]}とNTPsec ^{[ 79 ]の両方がchrony [ 80 ]}よりも問題が多いことが示唆されました。^{[ 81 ]}

NTP サーバーは、認証のためにパケットが暗号署名されていない限り、中間者攻撃に対して脆弱です。 ^{[ 82 ]}関連する計算オーバーヘッドにより、特にサービス拒否攻撃中は、ビジー状態のサーバーではこれが非現実的になる可能性があります。^{[ 83 ]}中間者攻撃によるNTP メッセージのなりすましは、クライアント コンピュータの時計を変更したり、暗号鍵の有効期限の回避に基づくさまざまな攻撃を可能にするために使用できます。 ^{[ 84 ]}偽の NTP メッセージの影響を受けることが確認されているサービスには、TLS、DNSSEC、さまざまなキャッシュ スキーム (DNS キャッシュなど)、ボーダー ゲートウェイ プロトコル(BGP)、ビットコイン、およびさまざまな永続ログイン スキームなどがあります。^{[ 85 ] [ 86 ]}

NTP は分散型サービス拒否攻撃に利用されています。^{[ 87 ] [ 88 ]}小さなクエリが NTP サーバーに送信され、その応答IP アドレスはターゲット アドレスに偽装されます。DNS増幅攻撃と同様に、サーバーははるかに大きな応答を返すため、攻撃者はターゲットに送信されるデータ量を大幅に増やすことができます。攻撃への参加を回避するには、NTP サーバー ソフトウェアをアップグレードするか、サーバーを外部クエリを無視するように構成することができます。^{[ 89 ]}

LI（閏年表示）： 2ビット

うるう秒の挿入または削除に関する警告：

• 0 = 警告なし
• 1 = 最後の1分は61秒です
• 2 = 最後の1分は59秒です
• 3 = 不明（クロック同期不良）

VN（バージョン番号）： 3ビット

NTPのバージョン番号。通常は4。

モード： 3ビット

関連付けモード:

• 0 = 予約済み
• 1 = 対称活性
• 2 = 対称パッシブ
• 3 = クライアント
• 4 = サーバー
• 5 = 放送
• 6 = コントロール
• 7 = プライベート

ストラタム： 8ビット

基準時計からの距離を示します。

• 0 = 無効
• 1 = プライマリサーバー
• 2～15歳＝中等教育
• 16 = 非同期

投票： 8ビット

連続するメッセージ間の最大間隔（log₂(秒)単位）。一般的な範囲は6～10秒です。

精度： 8ビット

システムクロックの精度を表す符号付きlog₂(秒)（例：-18 ≈ 1マイクロ秒）。

ルート遅延： 32ビット

基準クロックまでの総往復遅延時間（NTP短縮形式）。

ルート分散: 32ビット

基準クロックに対する総分散値（NTP短縮形式）。

参照ID ： 32ビット

特定のサーバーまたは基準クロックを識別します。解釈はStratumによって異なります。

参照タイムスタンプ： 64ビット

システムクロックが最後に設定または修正された時刻（NTPタイムスタンプ形式）。

発信元タイムスタンプ (org) : 64 ビット

リクエストが送信されたクライアント側の時刻（NTPタイムスタンプ形式）。

受信タイムスタンプ（rec）： 64ビット

最新のNTPメッセージが到着した時点の現地時刻（タイムスタンプ形式）。

送信タイムスタンプ (xmt) : 64ビット

応答が送信されたサーバー側の時刻（NTPタイムスタンプ形式）。

拡張フィールド：変数

NTP拡張機能のオプションフィールド（^{[ 5 ]}、セクション7.5を参照）。

キー識別子： 32ビット

クライアントとサーバー間で共有されるMD5キーを指定する符号なし整数。

メッセージダイジェスト（MD5）： 128ビット

認証に使用される、パケットヘッダーと拡張フィールドを対象としたMD5ハッシュ。

DHCPv4を使用すると、クライアントは初期ネットワーク設定の一環として時刻ソースを自動的に取得できます。これは、手動設定なしで動的な時刻同期を確保するために、管理ネットワークで一般的に使用されています。

EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

Europe/Oslo

• Allan variance – Measure of frequency stability in clocks and oscillators
• Clock network – Set of clocks that synchronized to same time
• International Atomic Time – Time standard based on atomic clocks
• IRIG timecode – Standard formats for transferring time information
• NITZ – Mechanism for time synchronisation on mobile devices
• NTP pool – Networked computers providing time synchronization
• Ntpdate – Networking protocol for clock synchronizationPages displaying short descriptions of redirect targets
• Precision Time Protocol – Network time synchronization protocol

• ネットワークタイムプロトコルバージョン4（NTPv4）の管理対象オブジェクトの定義。IETF。doi： 10.17487/ RFC5907。RFC 5907。
• DHCPv6 のネットワーク タイム プロトコル (NTP )サーバーオプション。IETF。doi : 10.17487 / RFC5908。RFC 5908。
• draft-ietf-ntp-data-minimization NTPクライアントデータ最小化ID

• 公式サイト
• 公式ストラタムワンタイムサーバーリスト
• IETF NTPワーキンググループ
• Microsoft Windowsの正確な時刻ガイドなど
• 時間とNTP論文
• NTP調査2005
• ntpdと互換性のある最新のNIST閏秒ファイル
• David L. Mills、「NTP時刻の簡潔な歴史：インターネット時刻管理者の告白」（PDF） 、 2021年2月7日取得