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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ネットワークタイムプロトコルNTPは)あるネットワーキングプロトコルのためのクロック同期を介してコンピュータシステム間のパケット交換、variable-待ち時間のデータネットワーク。 1985年以前から運用されているNTPは、現在使用されている最も古いインターネットプロトコルの1つです。 NTPはによって設計されたデビッドL.ミルズデラウェア大学

NTPをすることを意図して同期させるいくつかの内にすべて参加しているコンピュータをミリ秒単位協定世界時(UTC)。[1]3マルズーロのアルゴリズムの修正版である交差アルゴリズムを使用して、正確なタイムサーバーを選択し、変動するネットワーク遅延の影響を軽減するように設計されています。 NTPは通常、パブリックインターネット上で数十ミリ秒以内の時間を維持でき、理想的な条件下ローカルエリアネットワーク1ミリ秒を超える精度を達成できます。非対称ルートネットワークの輻輳は、100ミリ秒以上のエラーを引き起こす可能性があります。[2] [3]

プロトコルは通常、クライアント/サーバーモデルの観点から説明されますが、両方のピアが他方を潜在的なタイムソースと見なすピアツーピア関係でも簡単に使用できます[1]20の実装は、ポート番号123でユーザーデータグラムプロトコル(UDP)を使用してタイムスタンプ送受信します[4] [5]ブロードキャストまたはマルチキャストを使用することもでき、クライアントは最初のラウンドトリップ後に時間の更新を受動的にリッスンします。交換の調整。[3] NTPは、うるう秒が差し迫っていることを警告します調整は行われますが、現地のタイムゾーン夏時間に関する情報は送信されません[2] [3]

現在のプロトコルバージョン4に記載のように提案された標準である(NTPv4)であるRFC  5905RFC1305で指定されているバージョン3との下位互換性があります 

歴史

NTPは、David L.Millsによって設計されました

[更新が必要]

1979年、ニューヨークで開催れた全国コンピュータ会議で、大西洋横断衛星ネットワーク上で実行されるインターネットサービスの最初の公開デモンストレーションでネットワーク時間同期テクノロジが使用されました。技術は後から1981インターネット技術注(IEN)173に記載された[17]や公共プロトコルは、で文書化されたこと、それから開発されたRFC 778。このテクノロジーは、Helloルーティングプロトコルの一部としてローカルエリアネットワークに最初に導入され、ネットワークプロトタイピングで使用される実験的なオペレーティングシステムであるFuzzballルーターに実装されました 

他の関連するネットワークツールは、当時と現在の両方で利用可能でした。これらには、イベントの時刻を記録するためのDaytimeプロトコルTimeプロトコル、およびICMPタイムスタンプメッセージとIPタイムスタンプオプション(RFC 781)が含まれています。より完全な同期システムには、NTPのデータ分析とクロック規律アルゴリズムがありませんが、選択アルゴリズムを使用してすべてのクライアントのサーバーを指定するUnixデーモンtimedが含まれます。[18]およびNTP階層モデルと同様のサーバーの階層を使用するデジタル時刻同期サービス(DTSS)。  

1985年に、NTPバージョン0(NTPv0)がたFuzzballとUnixの両方に実装し、NTPv4に持続したNTPパケットヘッダと往復遅延とオフセット計算は、に記載されたRFC 958。当時利用可能なコンピュータとネットワークは比較的低速でしたが、通常、大西洋にまたがるリンクでは100ミリ秒超える精度が得られ、イーサネットネットワークでは数十ミリ秒の精度が得られました 

1988年には、NTPv1プロトコルのより多くの完全な仕様は、関連するアルゴリズムと、に掲載されたRFC 1059。それはで文書化実験結果とクロックフィルタアルゴリズムに描いたRFC 956と記述するための最初のバージョンだったクライアント・サーバーピア・ツー・ピア・モードを。 1991年には、NTPv1アーキテクチャ、プロトコルおよびアルゴリズムは、の記事を公開して、より広いエンジニアリングコミュニティの注意に持って来られたデビッドL.ミルズにおける通信に関するIEEEトランザクション[19]  

1989年に、ステートマシンを使用してNTPv2を定義するRFC 1119が公開され、その動作を説明する擬似コードが付けられました。それは、アルゴリズムの大部分とともに、両方ともNTPv4に生き残った管理プロトコルと暗号化認証スキームを導入しました。ただし、NTPv2の設計は、DTSSコミュニティから正式な正確性が欠如していると批判れ、クロック選択手順は、NTPv3以降のマルズーロのアルゴリズムを組み込むように変更されました[20] 

1992年には、RFC 1305はNTPv3を定義しました。 RFCには、参照クロックから最終クライアントまでのすべてのエラーの原因の分析が含まれていました。これにより、複数の候補者が同意しないように見える最適なサーバーを選択するのに役立つメトリックの計算が可能になりました。ブロードキャストモードが導入されました。  

その後、新しい機能が追加され、アルゴリズムが改善されると、新しいプロトコルバージョンが必要であることが明らかになりました。[21] 2010年に、RFC 5905は、 NTPv4のために提案された仕様を含む公開されました。それ以来、プロトコルは大幅に移行し、2014年の時点で、更新されたRFCはまだ公開されていません。[22]デラウェア大学からミルズが引退した後、リファレンス実装は現在、HarlanStennが主導するオープンソースプロジェクトとして維持されています[23] [24] 

時計の階層

Schriever AFB(コロラド)米国海軍天文台の代替マスタークロックは、NTPのストラタム0ソースです。
黄色の矢印は直接接続を示します。赤い矢印はネットワーク接続を示します。

NTPは、時間ソースの階層的な半層システムを使用します。この階層の各レベルは呼ばれ地層をし、上部の基準クロックのためにゼロから始まる番号が割り当てられます。ストラタムnサーバーに同期されたサーバーは、ストラタムn + 1で実行されます。この数値は、基準クロックからの距離を表し、階層内の周期的な依存関係を防ぐために使用されます。Stratumは、必ずしも品質や信頼性を示すものではありません。他のストラタム2タイムソースよりも高品質のストラタム3タイムソースを見つけるのが一般的です。[a]層0、1、2、および3の簡単な説明を以下に示します。

層0
これらは、原子時計、GPS、その他の電波時計などの高精度の計時装置です。これらは、接続されたコンピューターで割り込みとタイムスタンプをトリガーする非常に正確な1秒あたりのパルス信号を生成します。Stratum 0デバイスは、基準クロックとも呼ばれます。NTPサーバーは自身をストラタム0としてアドバタイズできません。NTPパケットでストラタムフィールドが0に設定されている場合は、ストラタムが指定されていないことを示します。[25]
層1
これらは、接続されているストラタム0デバイスから数マイクロ秒以内にシステム時刻が同期されているコンピューターです。Stratum 1サーバーは、健全性チェックとバックアップのために他のStratum1サーバーとピアリングする場合があります[26]これらはプライマリタイムサーバーとも呼ばれます。[2] [3]
層2
これらは、ネットワークを介してストラタム1サーバーに同期されるコンピューターです。多くの場合、ストラタム2コンピューターは複数のストラタム1サーバーにクエリを実行します。Stratum 2コンピューターは、他のStratum 2コンピューターとピアリングして、ピアグループ内のすべてのデバイスにより安定した堅牢な時間を提供することもできます。
層3
これらは、ストラタム2サーバーに同期されているコンピューターです。ピアリングとデータサンプリングにストラタム2と同じアルゴリズムを採用しており、ストラタム4コンピューターのサーバーとして機能することもできます。

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

階層に加えて、プロトコルは参照識別子(refid)の観点から各サーバーの同期ソースを識別することができます。

一般的な拍子記号(refid)コード
Refid [27] クロックソース
GOES 静止軌道環境衛星
GPS 全地球測位システム
GAL ガリレオポジショニングシステム
PPS 一般的な1秒あたりのパルス数
IRIG 射程間計装グループ
WWVB LFラジオWWVBフォートコリンズ、コロラド60 kHz
DCF LFラジオDCF77マインフリンゲン、DE 77.5 kHz
HBG LFラジオHBGPrangins、HB 75 kHz(動作停止)
MSF LFラジオMSFアンソーン、英国60 kHz
JJY LFラジオJJY福島、JP 40 kHz、佐賀、JP 60 kHz
LORC MFラジオロラン-Cステーション、100
TDF MF Radio Allouis、FR 162 kHz
CHU HFラジオCHUオタワ、オンタリオ
WWV コロラド州フォートコリンズの HFラジオWWV
WWVH HFラジオWWVHカウアイ島、ハワイ
NIST NIST電話モデム
使徒言行録 NIST電話モデム
USNO USNO電話モデム
PTB ドイツのPTB時間標準電話モデム
夫人 マルチリファレンスソース
XFAC Inter Face Associationが変更されました(IPアドレスが変更または失われました)
ステップ ステップ時間の変更、オフセットはパニックしきい値(1000秒)よりも小さいが、ステップしきい値(125ミリ秒)よりも大きい

タイムスタンプ

NTPで使用される64ビットのタイムスタンプは、秒の32ビット部分と秒の小数の32ビット部分で構成され、2 32秒(136年)ごとにロールオーバーするタイムスケールと2 −32の理論上の解像度を提供します。秒(233ピコ秒)。 NTPは1900年1月1日のエポック使用します。したがって、最初のロールオーバーは2036年2月7日に発生します。[28] [29]

NTPv4では、128ビットの日付形式が導入されています。秒は64ビット、小数秒は64ビットです。この形式の最も重要な32ビットは、ほとんどの場合、ロールオーバーのあいまいさを解決する時代番号です。[30] [31] Millsによれば、「分数の64ビット値は、光子が光速で電子を通過するのにかかる時間を解決するのに十分です。64ビット秒の値は、宇宙が暗くなるまで、明確な時間表現を提供します。」[32] [b]

クロック同期アルゴリズム

ラウンドトリップ遅延時間δ

一般的なNTPクライアントは、1つ以上のNTPサーバーを定期的にポーリングします。クライアントは、タイムオフセットとラウンドトリップ遅延を計算する必要があります2つのクロック間の絶対時間の差である時間オフセットθは、次の式で定義されます。

そして、往復遅延δによって

どこ

t 0は、要求パケット送信のクライアントのタイムスタンプです。
t 1は、要求パケット受信のサーバーのタイムスタンプです。
t 2は、応答パケット送信のサーバーのタイムスタンプであり、
t 3は、応答パケット受信のクライアントのタイムスタンプです。[1]19

オフセットの式を導出するには、要求パケットの場合、

応答パケットの場合、

θ解くと、時間オフセットの定義が得られます。

θδの値はフィルターを通過し、統計分析にかけられます。外れ値は破棄され、残りの3つの候補から時間オフセットの推定が導き出されます。次に、クロック周波数を調整してオフセットを徐々に減らし、フィードバックループを作成します[1]20

クライアントとサーバー間の着信ルートと発信ルートの両方に対称的な公称遅延がある場合、正確な同期が実現されます。ルートに共通の名目上の遅延がない場合、前進と後退の移動時間の差の半分の系統的バイアスが存在します。[33]

ソフトウェアの実装

ストラタム2サーバーの状態を照会するために使用されているNTP管理プロトコル・ユーティリティーntpq。

リファレンス実装

NTPリファレンス実装は、プロトコルとともに、20年以上にわたって継続的に開発されてきました。新しい機能が追加されたため、下位互換性が維持されています。これには、特に時計を制御するためのいくつかの機密性の高いアルゴリズムが含まれており、異なるアルゴリズムを使用するサーバーと同期すると誤動作する可能性があります。このソフトウェアは、パーソナルコンピュータを含むほぼすべてのコンピューティングプラットフォームに移植されています。Unixではntpdと呼ばれるデーモンとして、またはWindowsではサービスとして実行されます。参照クロックがサポートされており、それらのオフセットはリモートサーバーと同じ方法でフィルタリングおよび分析されますが、通常はより頻繁にポーリングされます。[1]15–19 この実装は2017年に監査され、多くの潜在的なセキュリティ問題が見つかりました。[34]

SNTP

Simple Network Time ProtocolSNTP)は、NTPのそれほど複雑ではない実装であり、同じプロトコルを使用しますが、長期間にわたって状態保存する必要はありません[35]一部の組み込みシステムや、完全なNTP機能が必要とされないアプリケーションで使用されます[36]

Windows時間

すべてのMicrosoft Windows以来のバージョンのWindows 2000は、 Windowsタイムサービス(のW32Time)が含まれる[37] NTPサーバーにコンピュータのクロックを同期する機能を持っています。

W32Timeは元々、Kerberosバージョン5認証プロトコルの目的で実装されました。これには、リプレイ攻撃を防ぐために正しい値から5分以内の時間が必要でしたWindows2000およびWindowsXPのバージョンはSNTPのみを実装しており、NTPバージョン3標準のいくつかの側面に違反しています。[38]

以降でWindows Server 2003のおよびWindows Vistaでは、のW32TimeはNTPv3の重要な一部との互換性になりました。[39] Microsoftは、W32Timeは1秒の精度で時刻同期を確実に維持できないと述べています。[40]より高い精度が必要な場合、Microsoftは新しいバージョンのWindowsまたは異なるNTP実装を使用することをお勧めします。[41]

始まるのWindows 10のバージョン1607とWindows Serverの2016、のW32Timeは、ある特定の動作条件下で50ミリ秒または1秒の1秒の時間精度に到達するように構成することができます。[42] [40] [43]

OpenNTPD

2004年、Henning Brauerは、セキュリティに重点を置き、特権分離設計を含むNTP実装であるOpenNTPDを発表しました。OpenBSDユーザーのより単純な一般的なニーズをより厳密に対象としていますが、既存のNTPサーバーとの互換性を保ちながら、プロトコルセキュリティの改善も含まれています。ポータブルバージョンは、Linuxパッケージリポジトリで入手できます。

Ntimed

新しいNTPクライアントntimedは2014年にPoul-Henning Kampによって開始されました。[44]新しい実装は、リファレンス実装の代わりとしてLinux Foundationによって後援されています。これは、から新しい実装を作成する方が簡単であると判断されたためです。リファレンス実装のサイズを縮小するよりもスクラッチ。正式にはリリースされていませんが、ntimedはクロックを確実に同期できます。[45]

NTPsec

NTPsecは、体系的にセキュリティが強化されたリファレンス実装のフォークです。フォークポイントは2015年6月で、2014年の妥協の急増に対応していました。[指定] 2017年10月に出荷された最初の製品リリース。[46]安全でない機能の削除、廃止されたハードウェアのサポートの削除、および廃止されたU​​nixバリアントのサポートにより、NTPsecは元のコードベースの75%を削減し、残りをより監査しやすくすることができました。[47] 2017年のコードの監査では、元のリファレンス実装には存在しなかった2つを含む、8つのセキュリティ問題が示されましたが、NTPsecは、リファレンス実装に残った他の8つの問題に悩まされていませんでした。[48]

chrony

chronyc、ソースとアクティビティ情報を表示します。ターミナルウィンドウの下のアーチのLinux

chronyはデフォルトでRedHatディストリビューション[49]に付属しており、Ubuntuリポジトリで利用できます。[50] chronyは、不安定な、スリープモードに入る、またはインターネットへの断続的な接続がある通常のコンピューターを対象としています。[51] chronyは、はるかに不安定な環境である仮想マシン用にも設計されています。リソース消費(コスト)が低いという特徴があり、タイムスタンプの精度を高めるためにPrecision TimeProtocolハードウェアをサポートしています。[52]これには2つの主要なコンポーネントがあります。コンピュータの起動時に実行されるデーモンであるchronydと、構成のためのユーザーへのコマンドラインインターフェイスであるchronycです。非常に安全で、わずかなインシデントであると評価されており[53]、その利点は、不必要な複雑さを回避するためにゼロから記述されたコードの多様性です。[54]ネットワークタイムセキュリティ(NTS)のサポートがバージョン4.0で追加されました。[55] chronyは、GNU General Public Licenseバージョン2利用可能であり、1997年にRichard Curnowによって作成され、現在MiroslavLichvarによって保守されています。[56]

うるう秒

日にうるう秒イベント、ntpdのコンフィギュレーションファイル、添付の基準クロック、またはリモートサーバのいずれかからの通知を受信します。 NTPクロックが実際にあるため、時間が表示されなければならないことを要件と、イベント中に停止されますがする厳密に増加、どのプロセスも原因クエリシステム時刻は、イベントの順序を保持し、小さな量によって増加することを。負のうるう秒が必要になった場合は、23:59:58、00:00:00の順序で削除され、23:59:59はスキップされます。[57]

うるう秒スミアリングと呼ばれる別の実装では、UTC時間の正午から正午までの24時間の間に、うるう秒を段階的に導入します。この実装は、Google(内部およびパブリックNTPサーバーの両方)とAmazonAWSによって使用されます。[58]

セキュリティ上の懸念

NTPコードベースのリファレンス実装で特定されたセキュリティ上の問題は他にもわずかですが、2009年に発生した問題が重大な懸念の原因でした。[59] [60]プロトコルは、その歴史全体にわたって改訂とレビューを受けています。リファレンス実装のコードベースは、数年にわたっていくつかのソースからセキュリティ監査を受けています。[61]

スタックバッファオーバーフローが2014年に発見し、パッチを当てたを活用[62] アップルは、それが初めての自動更新機能を使用したことを、この脆弱性について十分に心配していました。[63]ルーチンにreturnステートメントがないなど、一部の実装エラーは基本的なものであり、ルートデーモンでNTPの一部のバージョンを実行しているシステムへの無制限のアクセスにつながる可能性があります。 BSDなどのルートデーモンを使用しないシステムは、この欠陥の影響を受けません。[64]

Linux Foundationのコアインフラストラクチャイニシアチブに代わって実施された3つのNTP実装の2017年のセキュリティ監査では、セキュリティの観点から、NTP [65] [66]とNTPsec [67]の両方がChrony [68]よりも問題があることが示唆されました。[69]

パケットが認証のために暗号で署名されていない限り NTPサーバーはman-in-the-middle攻撃の影響を受けやすい可能性があります。[70]関連する計算オーバーヘッドは、特にサービス拒否攻撃の際に、ビジー状態のサーバーでこれを非現実的にする可能性があります[71]中間者攻撃によるNTPメッセージのなりすましを使用して、クライアントコンピュータの時計を移動し、暗号化キーの有効期限のバイパスに基づいて多数の攻撃を許可することができます。[72]識別された偽のNTPメッセージの影響を受けるサービスには、TLSDNSSEC、さまざまなキャッシュスキーム(DNSキャッシュなど)、BGP、ビットコイン、およびいくつかの永続的なログインスキームがあります。[73] [74]

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

TLSとAEADを備えたNTPの安全なバージョンであるNetworkTime Security(NTS)は、現在IETFのNTPワーキンググループによって提案されインターネットドラフトです。[78]

も参照してください

注意事項

  1. ^ 電気通信システムは、クロック層に異なる定義を使用します
  2. ^ 2 -64秒程度である54 zeptoseconds(光が16.26ピコメートル、または約0.31×旅行をするだろうボーア半径)、および2 64秒程度である億585年

参考文献

  1. ^ a b c d e f David L. Mills(2010年12月12日)。コンピュータネットワーク時刻同期:ネットワーク時刻プロトコルテイラーアンドフランシス。pp。12–。ISBN 978-0-8493-5805-02014年7月18日にオリジナルからアーカイブされました取得した16年10月2016
  2. ^ a b c 「エグゼクティブサマリー:コンピュータネットワークの時刻同期」2011年11月2日にオリジナルからアーカイブされました2011年11月21日取得
  3. ^ bはCのD "NTPよくある質問"NTPプロジェクト。2011年9月6日にオリジナルからアーカイブされました2011年8月27日取得
  4. ^ 「ポート番号」Internet Assigned Numbers Authority(IANA)。2001年6月4日にオリジナルからアーカイブされました2011年1月19日取得
  5. ^ 「16ページ」2018-01-01にオリジナルからアーカイブされました20119月26日取得
  6. ^ RFC 958ネットワークタイムプロトコル(NTP)、1985年9月。
  7. ^ RFC 1059ネットワークタイムプロトコル(バージョン1)の仕様と実装、1988年7月。
  8. ^ RFC 1119ネットワークタイムプロトコル(バージョン2)の仕様と実装、1989年9月。
  9. ^ RFC 1305ネットワークタイムプロトコル(バージョン3)の仕様、実装、および分析、1992年3月。
  10. ^ RFC 5905ネットワークタイムプロトコルバージョン4:プロトコルとアルゴリズムの仕様、2010年6月。
  11. ^ RFC 7822ネットワークタイムプロトコルバージョン4(NTPv4)拡張フィールド、2016年3月。
  12. ^ RFC 1361 Simple Network Time Protocol(SNTP)、1992年8月。
  13. ^ RFC 1769 Simple Network Time Protocol(SNTP)、1995年3月。
  14. ^ IPv4、IPv6、およびOSI用のRFC 2030 Simple Network Time Protocol(SNTP)バージョン4、 1996年10月。
  15. ^ IPv4、IPv6、およびOSI用のRFC 4330 Simple Network Time Protocol(SNTP)バージョン4、 2006年1月
  16. ^ RFC 778 DCNETインターネットクロックサービス、1981年4月。
  17. ^ DLミルズ(1981年2月25日)、DCNETホストでの時刻同期からアーカイブ、オリジナルの1996年12月30日に
  18. ^ 「TIMED(8)」UNIXシステムマネージャのマニュアル2011年7月22日オリジナルからアーカイブ2017年9月12日取得
  19. ^ デビッドL.ミルズ(1991年10月)。「インターネット時刻同期:ネットワーク時刻プロトコル」(PDF)通信に関するIEEEトランザクション39(10):1482–1493。土井10.1109 /26.1030432016年6月10日にオリジナルからアーカイブ(PDF)2017116日取得
  20. ^ 「RFC1305」IETF:インターネットエンジニアリングタスクフォース。 IETF。2019年12月11日にオリジナルからアーカイブされました2019年12月6日取得クロック選択手順が変更され、2つの並べ替え/破棄ステップの最初のステップが削除され、Marzulloによって最初に提案され、後にDigital TimeServiceに組み込まれたアルゴリズムに置き換えられました。これらの変更は、NTPの通常の操作やさまざまなバージョンとの互換性に大きな影響を与えることはありませんが、正式な正しさのステートメントの基礎を提供します。
  21. ^ David L. Mills(2010年11月15日)。コンピュータネットワーク時間同期:地球と宇宙のネットワーク時間プロトコル、第2版CRCプレス。NS。377. ISBN 978-1-4398-1464-2
  22. ^ 「今後の予定」、ネットワーク時刻同期研究プロジェクトアーカイブ2014年12月23日に元からは、取得した12月24日の2014
  23. ^ 「NTPにはお金が必要です:財団は答えですか?」InformationWeek2015年3月23日。2015年4月10日のオリジナルからアーカイブ2015年4月4日取得
  24. ^ 「NTPの運命は「ファーザータイム」に影響を与えるInformationWeek2015年3月11日。2015年4月10日のオリジナルからアーカイブ2015年4月4日取得
  25. ^ RFC 5905、p。21
  26. ^ 「ネットワークタイムプロトコル:ベストプラクティスホワイトペーパー」2013年10月1日にオリジナルからアーカイブされました取得した15年10月2013
  27. ^ " ' ntpq -p'出力"NLUG.ML1.co.uk2018-11-12にオリジナルからアーカイブされました20181112日取得
  28. ^ デビッドL.ミルズ(2012年5月12日)。「NTPの時代と時代の番号付け」2016年10月26日にオリジナルからアーカイブされました取得した24年9月2016
  29. ^ W。リチャードスティーブンス; ビル・フェナー; Andrew M. Rudoff(2004)。UNIXネットワークプログラミングアディソン-ウェスリープロフェッショナル。pp。582–。ISBN 978-0-13-141155-52019-03-30にオリジナルからアーカイブされました2016年10月16日取得
  30. ^ 「NTPが時間を表す方法(コンピュータネットワークの時刻同期)」2017年6月15日にオリジナルからアーカイブされました2018720日取得
  31. ^ 「さまざまなシステムにおける2036/2038年の問題とタイムプルーフの調査」2017年3月14日 2018721日のオリジナルからアーカイブ2018720日取得
  32. ^ デラウェア大学デジタルシステムセミナーのプレゼンテーション、David Mills、2006年4月26日
  33. ^ 後藤徹; 今村健一; 金子晃(2002)。ダブルパケット方式による非対称ネットワーク下でのNTP時間オフセットの改善精密電磁測定に関する会議。pp。448–449。土井10.1109 /CPEM.2002.1034915ISBN 0-7803-7242-5
  34. ^ 「ペネトレーションテスト-レポートNTP01.2017」(PDF)。 Cure53。 2017. 2018-12-01のオリジナルからアーカイブ(PDF)20197月3取得
  35. ^ 「ネットワークタイムプロトコルバージョン4:プロトコルとアルゴリズムの仕様」。 2010年6月。p。 54.2012-09-10にオリジナルからアーカイブされました。 2012年826日取得Simple Network Time Protocol(SNTPv4)[...]と呼ばれるNTPのサブセットに準拠するプライマリサーバーとクライアントは、緩和アルゴリズムを実装する必要はありません[...]完全に開発されたNTPv4実装は[.. 。]複数のアップストリームサーバーと複数のダウンストリームサーバーを備えたサーバー[...]これらの考慮事項以外に、NTPおよびSNTPサーバーとクライアントは完全に相互運用可能であり、混在させることができます[...]
  36. ^ IPv4、IPv6、およびOSI用のSimple Network Time Protocol(SNTP)バージョン4土井10.17487 / RFC4330RFC 4330
  37. ^ 「WindowsTimeServiceテクニカルリファレンス」technet.microsoft.com。2011年8月17日。2011年9月6日にオリジナルからアーカイブされました20119月19日取得
  38. ^ 「NTP.orgのWindowsタイムサービスページ」Support.NTP.org2008-02-25。2017年5月14日にオリジナルからアーカイブされました20175月1取得
  39. ^ 「Windowsタイムサービスのしくみ」technet.microsoft.com。2010-03-12。2011年9月24日にオリジナルからアーカイブされました20119月19日取得
  40. ^ a b "高精度環境用にWindowsTimeサービスを構成するためのサポート境界"Microsoft2011-10-19。2009年1月12日にオリジナルからアーカイブされました2008年12月10日取得
  41. ^ ネッドパイル(2007-10-23)。「高精度のW32time要件」Microsoft2012-10-17にオリジナルからアーカイブされました2012年826日取得
  42. ^ 「WindowsServer2016の正確な時間」technet.microsoft.com2016年12月2日にオリジナルからアーカイブされました2016年127日取得
  43. ^ dahavey。「高精度時間のサポート境界」docs.microsoft.com 2021724日取得
  44. ^ ポール・ヘニング、カンプ。「20140926–もう一度時間をかけて遊ぶ」PHKのバイクシェッド2019年12月20日にオリジナルからアーカイブされました検索された4年6月2015年
  45. ^ ポール・ヘニング、カンプ。「ネットワーク時刻同期ソフトウェア、NTPDの置き換え」ntimedgitリポジトリのREADMEファイルGithub。2015年8月2日にオリジナルからアーカイブされました検索された4年6月2015年
  46. ^ 「セキュアネットワークタイムプロトコル(NTPsec)配布」2019-01-13にオリジナルからアーカイブされました2019年1月12日取得
  47. ^ Liska、Allan(2016年12月10日)。NTPセキュリティ:クイックスタートガイド押してください。pp。80–。ISBN 978-1-4842-2412-0
  48. ^ 「ペネトレーションテスト-レポートNTPsec01.2017」(PDF)Cure53。2017. 2019-07-04のオリジナルからアーカイブ(PDF)20197月3取得
  49. ^ Lichvar、Miroslav(2016年7月20日)。「PTPとNTPを組み合わせて、両方の長所を活用する」Red Hat EnterpriseLinuxブログRedHat2016年7月30日にオリジナルからアーカイブされまし2017年11月19日取得Red Hat Enterprise Linux 7.0(および現在はRed Hat Enterprise Linux 6.8)以降、より用途の広いNTP実装もchronyパッケージを介して提供されます。
  50. ^ リヒテンヘルド、フランク。「パッケージ:chrony(2.1.1-1)[ユニバース]」UbuntuパッケージUbuntuパッケージ。2017年11月19日にオリジナルからアーカイブされまし2017年11月19日取得ネットワークタイムプロトコルの多様な実装
  51. ^ 両方、デビッド。「NTPをChronyで管理する」Opensource.com2019年6月29日にオリジナルからアーカイブされました2019年6月29日取得
  52. ^ Lichvar、Miroslav(2018年9月18日)。"chrony – chrony.conf(5)"クロニープロジェクト。クロニープロジェクト2020年8月2日取得このディレクティブは、指定されたネットワークインターフェイスとの間で送受信されるNTPパケットのハードウェアタイムスタンプを有効にします。
  53. ^ ハイデリッチ、マリオ(2017年8月)。「ペネトレーションテスト-レポートクロニー08.2017」(PDF)Cure53.deチーム。 wiki.mozilla.org、別名MozillaWikiまたはWikiMO。2017年10月5日にオリジナル(PDF)からアーカイブされまし2017年11月19日取得2017年8月の11日間のリモートテストに耐えることは、Chronyが堅牢で強力であり、セキュリティを念頭に置いて開発されたことを意味します。
  54. ^ 「ネットワーク時間の確保」コアインフラストラクチャイニシアチブ、LinuxFoundationコラボレーティブプロジェクトコアインフラストラクチャイニシアチブ。2017年9月27日 2017年10月28日のオリジナルからアーカイブ2017年11月19日取得要約すると、Chrony NTPソフトウェアは堅実であり、信頼できると見なすことができます。
  55. ^ 「chrony / chrony.git-Chronyプロジェクトの公式Gitリポジトリ」git.tuxfamily.org 2021-07-31を取得
  56. ^ 「chronyの紹介」TuxFamily、非営利団体chrony。2009年12月9日にオリジナルからアーカイブされまし2017年11月19日取得このソフトウェアは、Linux、FreeBSD、NetBSD、macOS、およびSolarisでサポートされています。
  57. ^ デビッドミルズ。「NTPタイムスケールとうるう秒」2013年9月7日にオリジナルからアーカイブされました取得した15年10月2013
  58. ^ 「GoogleDevelopersLeapSmear」2019年4月4日にオリジナルからアーカイブされました2019年4月4日取得
  59. ^ 「セキュリティ通知」Support.NTP.org2009-12-10 取得した2011年1月12日を
  60. ^ 「CiscoIOSソフトウェアネットワークタイムプロトコルパケットの脆弱性」シスコシステムズ2009年9月23日。2020年6月11日のオリジナルからアーカイブ2020年6月11日取得
  61. ^ 「コード監査」Support.NTP.org2009-06-13 取得した2011年1月12日を
  62. ^ 「ネットワークタイムプロトコルの脆弱性(アップデートC)| ICS-CERT」Ics-cert.us-cert.gov。2014年12月20日にオリジナルからアーカイブされました取得した2015年4月15日を
  63. ^ カニンガム、アンドリュー(2014年12月23日)。「Appleは自動的にMacにパッチを適用して、深刻なNTPセキュリティの欠陥を修正します」arstechnica。2015年4月15日にオリジナルからアーカイブされました2015年4月29日取得
  64. ^ フェアヘッド、ハリー(2014年12月23日)。「NTP最新のオープンソースセキュリティ問題」私はプログラマーです。2014年12月24日にオリジナルからアーカイブされまし取得した24年12月2014
  65. ^ ウェイバックマシンで2014-02-19にアーカイブされたNTPSecurityNoticeページ
  66. ^ NVDNIST製品検索NTP
  67. ^ ウェイバックマシンNVDNIST製品検索NTPsec アーカイブ2020-06-26
  68. ^ ウェイバックマシン2020-06-26に アーカイブされたNVDNIST製品検索Chrony
  69. ^ 「CII監査は最も安全なNTP実装を識別します」LinuxFoundation。2017年9月28日。2018-02-03のオリジナルからアーカイブ20197月3取得
  70. ^ ネットワークタイムプロトコルバージョン4:自動キー仕様IETF。2010年6月。doi10.17487 / RFC5906RFC 5906
  71. ^ 「NTPセキュリティ分析」2013年9月7日にオリジナルからアーカイブされまし取得した11年10月2013
  72. ^ Jose Selvi(2014-10-16)。「HTTPStrictTransport Securityのバイパス」(PDF)2014-10-18にオリジナル(PDF)からアーカイブされまし2014年1016日取得
  73. ^ Aanchal Malhotra; アイザックE.コーエン; Erik Brakke&Sharon Goldberg(2015年10月20日)。「ネットワークタイムプロトコルへの攻撃」(PDF)NDSS2015年10月22日にオリジナル(PDF)からアーカイブされまし取得した27年10月2015
  74. ^ 「ネットワークタイムプロトコルへの攻撃」www.cs.bu.edu2015-10-24にオリジナルからアーカイブされまし2015年1027日取得
  75. ^ グッディン、ダン(2014-01-13)。「ゲームサイトを破壊する新しいDoS攻撃は、壊滅的な100Gbpsの洪水をもたらします」ArsTechnica2014-01-24にオリジナルからアーカイブされました2014年1月25日取得
  76. ^ リー、デイブ(2014-02-11)。「インターネットの脅威に対する巨大なハッキング「未来の醜い兆候」」BBC。2014-02-11にオリジナルからアーカイブされました取得した2014年2月12日を
  77. ^ 「DRDoS / ntpdcmonlistコマンドを使用した増幅攻撃」support.NTP.org2010-04-24。2014-03-30にオリジナルからアーカイブされました2014年4月13取得
  78. ^ "draft-ietf-ntp-using-nts-for-ntp-19"datatracker.ietf.org 2021-07-31を取得

さらに読む

外部リンク