|
Network Time Protocol
Network Time Protocol（ネットワーク・タイム・プロトコル、NTP）は、パケット交換による遅延時間が変動するネットワーク上のコンピュータシステム間で時刻同期させるための通信プロトコルである。1985年以前から運用されており、現在使用されている中で最も古いインターネットプロトコルの1つである。NTPは、デラウェア大学のデイヴィッド・L・ミルズによって設計された。NTPによって提供される数ミリ秒以下の誤差の時刻同期は、情報システムにおいて時刻で管理される様々なデータや処理の整合性を保つために必要である。 概要NTPは、全ての参加コンピュータを協定世界時(UTC)の数ミリ秒以内の時刻に同期させることを目的としている[1]:3。 ネットワークに接続され、互いにデータの交換を行う機器において、各機器が持つ時計（以下、各機器が持つ時計を「RTC」として説明する）の時刻が機器間で異なると、時刻に依存した機器間のデータ交換、例えば電子メールやファイルの送受信、ログの配信などに異常をきたすおそれがある。よって、RTCの時刻は機器間で互いに同期していることが望ましい。ネットワークに接続される機器のRTCを正しい時刻に合わせる古典的な方法としてTime Protocolがある。Time Protocolは正しい時刻を提供するサーバから各機器が時刻値を取得する方法を定めている。しかし Time Protocol を用いて取得した時刻値にはサーバから機器に時刻値が到達するまでの通信時間が含まれない。よって、取得した時刻値には通信時間に起因する遅れの誤差が含まれてしまいRTCを正しい時刻に同期できない。NTPは通信時間による時刻値の誤差を小さくする工夫がなされた時刻同期のためのプロトコルである。 正確なタイムサーバを選択するために、マルズーロのアルゴリズムの修正版である交差アルゴリズムを使用し、ネットワーク遅延の変化の影響を軽減するように設計されている。NTPは通常、インターネット上で数十ミリ秒以内の時間を維持することができ、理想的な条件の下ではLAN上で1ミリ秒以下に誤差を抑えることができる。非対称なルートやネットワークの輻輳により、100ミリ秒以上のエラーが発生することがある[2][3]。更に後に追加されたオプション仕様ではNTPインターリーブモードで約5マイクロ秒[4]、ハードウェアタイムスタンプで約100ナノ秒[5]の誤差に抑えることも可能になっている。 このプロトコルは通常、クライアントサーバモデルで記述されるが、相手側をタイムサーバとみなすことでピアツーピアネットワークにおいても使用することができる[1]:20。実装としては、UDPのポート番号123を使用する[4][5][注釈 1]。また、ブロードキャストやマルチキャストを使用することもでき、この場合、クライアントは最初に時刻同期のためにサーバと通信した後、時間の更新を受動的に受信することができる[3]。NTPは、直近の閏秒の情報は送信するが、タイムゾーンや夏時間に関する情報は送信しない[2][3]。 最新のプロトコルバージョンはバージョン4(NTP v4)で、RFC 5905で文書化されている。これはRFC 1305で規定されているバージョン3との後方互換性があり RFC 4330 (SNTP v4) の置き換えでもある。その後もRFC 7822, 8573, 9109 が発行されているが NTP v4 の拡張フィールドとメッセージ認証コードについての補足、認証コードの推奨アルゴリズム変更、ソースポートのランダマイゼーションの推奨と実質的な変更はない。(SNTP v4 については全く触れられていない) 歴史 NTP関連のRFCの履歴 1975 — – 1980 — – 1985 — – 1990 — – 1995 — – 2000 — – 2005 — – 2010 — – 2015 — – 2020 — – 1979年、ニューヨークで開催された全米コンピュータ会議において、大西洋横断衛星ネットワーク上で動作するインターネットサービスの最初の公開デモンストレーションが行われ、ここでネットワーク時刻同期技術が使用された。この技術は後に1981年のInternet Experiment Note (IEN) 173[17]に記述され、公開プロトコルが開発され、RFC 778で文書化された。この技術は最初、Helloルーティングプロトコルの一部としてLANに展開され、ネットワークプロトタイピングに使用される実験的なオペレーティングシステムであるファズボールルータに実装され、長年にわたって使用された。 その他の関連するネットワークプロトコルは、現在でも使用可能である。その中には、イベントの時刻を記録するためのDAYTIMEプロトコルとTIMEプロトコルや、ICMPのタイムスタンプ、RFC 781に規定されるIPタイムスタンプがある。より完全な同期システムとしては、UNIXデーモンのtimedがあり、これはリーダー選出アルゴリズムを使って全てのクライアントのためのサーバを指定する[18]。デジタル時刻同期サービス(DTSS)は、NTPの階層モデルに似たサーバの階層を使用している。 1985年、NTPバージョン0(NTPv0)がファズボールとUNIXの両方に実装され、NTPパケットヘッダとラウンドトリップ遅延とオフセットの計算がRFC 958で文書化された。当時は比較的遅いコンピュータとネットワークしか利用できなかったにもかかわらず、大西洋のスパニングリンクでは通常100ミリ秒以上、イーサネットネットワークでは数十ミリ秒の精度が得られた。 1988年、NTPv1プロトコルのより完全な仕様と関連アルゴリズムがRFC 1059で公開された。この仕様は、実験結果とRFC 956で文書化されたクロックフィルタアルゴリズムに基づいており、クライアントサーバモードとピアツーピアモードを記述した最初のバージョンだった。1991年、NTPv1のアーキテクチャ、プロトコル、アルゴリズムについてのデイヴィッド・L・ミルズの論文[19]がIEEE Transactions on Communicationsに掲載され、エンジニアのコミュニティ内で広く注目を集めた。 1989年にRFC 1119が発行された。このRFCでは、状態機械を用いてNTPv2を定義し、その動作を記述するための疑似コードが含まれている。これは、管理プロトコルと暗号化認証スキームを導入し、アルゴリズムの大部分とともに NTPv4にも引き継がれている。しかし、NTPv2の設計はDTSSのコミュニティから正当性を欠いていると批判され、クロック選択手順はNTPv3以降でマルズーロのアルゴリズムを組み込むように修正された[20]。 1992年にRFC 1305でNTPv3が定義された。このRFCでは、参照クロックから最終的なクライアントに至るまでの全てのエラー発生源の分析が含まれており、これにより、複数の候補の間で一致しないように見える場合に、最適なサーバを選択するのに役立つメトリックの計算が可能になった。また、ブロードキャストモードが導入された。 その後、新しい機能が追加されたり、アルゴリズムが改良されたことにより、新しいプロトコルのバージョンが必要であることが明らかになった[21] 。2010年には、RFC 5905でNTPv4の仕様案が提示された。その後、プロトコルは大きく前進しているが、2014年現在、更新されたRFCはまだ公開されていない[22]。ミルズが大学教授を引退したのに伴い、Harlan Stennが率いるオープンソースプロジェクトとしてリファレンス実装が維持されている[23][24]。 時刻同期の仕組み処理の概略
NTPプロトコル上では協定世界時 (UTC) を使って時刻を送受信する。 NTPサーバプログラムが他のNTPサーバに接続すると、上位NTPサーバとのネットワーク通信の遅延を継続的に計測し、受け取った時刻情報を補正して自動的にミリ秒単位の精度で自機・OSの時計を校正する。このほか後述するように自機・OSの時計の進み遅れ度合いも校正したり、他のNTPサーバからの問い合わせに応えて時刻も提供する機能が実装されることがある。 クロック階層 NTPでは、時間源の階層的システムを使用している。階層の各レベルはstratumと呼ばれる。最上位の基準クロックをstratum 0とし、stratum 0に同期しているサーバをstratum 1とする。以降、stratum nに同期しているサーバをstratum n+1とする。この番号は、基準クロックからの距離を表し、階層内での依存関係のループを防ぐために使用される。stratumの値は必ずしも品質や信頼性を示すものではなく、あるstratum 2サーバとstratum 3サーバを比較して、stratum 3サーバの方が高品質ということもあり得る。 以下に、stratum0、1、2、3について簡単に説明する。
Stratumの上限は15で、stratum 16はデバイスが非同期であることを示すために使用される。各コンピュータ上のNTPアルゴリズムは、ベルマン・フォード最短経路スパニングツリーを構築するために相互に作用し、全てのクライアントからstratum 1サーバへの累積ラウンドトリップ遅延を最小化する[1]:20。 NTPプロトコルは、stratumのほか、参照識別子(refid、4オクテット)を使用して、各サーバの同期化元を特定することができる。Stratum 1のサーバは、同期しているstratum 0サーバの具体的な実装を最長4文字のASCIIコードにて表現する。以下はRFC5905に定められているもの。
Stratum 2以上(階層としては下層)のサーバは、同期先のNTPサーバのIPアドレスをrefidに記述する。この情報は、NTPサーバ同士で同期先がループするのを防ぐ目的で使用される。IPv4アドレスはそのまま記述するが、IPv6アドレスの場合はそのmd5ハッシュを計算した上で、ハッシュ値の最初の4オクテットを使用する。 タイムスタンプNTPで使用される64ビットのタイムスタンプは、秒を表す32ビット部分と、秒未満の時間を表す32ビット部分で構成されている。秒未満の時間は、2-32秒（233ピコ秒）の理論的な分解能を持っている。秒を表す部分は32ビット符号なし整数であり、起点（エポック）としている1900年1月1日 0時0分0秒(UTC)からの経過秒数を表す。この値は、起点からから232-1秒、すなわち42億9496万7295秒（約136年）で桁あふれする。最初の桁あふれは2036年2月7日 6時28分15秒の次の秒に発生し[27][28][29]、起点と認識されてNTPが誤動作すると予想されている。これを2036年問題という。UNIX[注釈 2]にはこの問題が複数の箇所で今後顕在化するとみられるが（例: 2038年問題）、このNTPについても該当する。 RFC 4330には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒(UTC)を起点として計算することで2036年問題を回避する方法が書かれている[27]。 NTPv4では128ビットのタイムスタンプが導入されており、秒と秒未満にそれぞれ64ビットを割り当てている。秒を表す64ビットのうち、半分の32ビットは現行のNTPと同じであり、残りの32ビットは、桁あふれの回数を表すEra Number（時代番号）である[30][31]。ミルズによれば、「秒未満の64ビット値は、光子が光速で電子を通過するのにかかる時間を見分けるのに十分な分解能である。もう1つの64ビットの値は、宇宙が薄暗くなる（宇宙の終焉）までの時間を明確に表現するのに十分である。」[32][注釈 3] クロック同期アルゴリズム 一般的なNTPクライアントは、1つ以上のNTPサーバに対してポーリングを行う。クライアントは、タイムオフセットとラウンドトリップタイムを計算する。 タイムオフセット θ は、クライアントとサーバのクロック間の絶対時間の差であり、次式で計算される。 ラウンドトリップタイム δ は、パケットの往復時間からサーバの処理時間を引いたものであり、次式で計算される。 ここで、
である[1]:19。 θとδの値はフィルタを通過し、統計的分析が行われる。外れ値は破棄され、残りの候補の中で最も優れた3つの候補から時間オフセットの推定値が導出される。その後、オフセットが徐々に減少するようにクロック周波数が調整され、フィードバックループを形成する[1]:20。 正確な同期化は、往路と復路の通信時間がほぼ等しい場合に達成される。両者に差がある場合は、その差の2分の1が誤差になる可能性がある[33]。極端な例では、通信の往復に合計10秒掛かった場合に最大で約5秒の誤差が発生する。 運用NTPサーバを設定する際は、サーバのIPアドレスを直接指定するのではなく、ホスト名を用いて指定すべき、とされている（RFC4330による）[34]。 LAN内部にクライアント台数がそれなりにある場合には、外部へのトラフィックおよび外部NTPサーバの負荷を最小限にするため、LAN内にNTPサーバとして稼動できる機器[注釈 4]を用意し、この機器（内部NTPサーバ）をプロバイダなどの外部NTPサーバに接続し、各クライアントはこの内部NTPサーバに接続する設定を行うと良い。 ルーターやクライアントパソコンなどのネットワーク上の各機器では、前述のようなNTPサーバにアクセスして、機器内部の時計の時刻をNTPサーバの時刻に合わせることで内部時計の誤差が少なくなる。 ドリフトの修正NTPサーバの実装の多くでは、時刻の校正のみならず、時計の進み遅れの度合いの校正も行う。一般的にコンピュータ内部の時計は、ハードウェアの時計が提供する時刻をそのまま利用する場合と、割り込みなどによりソフトウェア的に時計を進める場合がある。いずれの場合も、設計状態での時計は数ppm以上（1ppmは百万分の一、およそ10日で1秒程度の精度）の狂いがあるため、他のNTPサーバからの時刻と自機の時計を数回比較した後、時計の進み遅れの度合い（ドリフト）も修正する必要がある。さらに気温変動など外乱要因による2次以上のドリフト（上述した進み遅れ度合いの変化）も存在するが、多くのNTPサーバでは一次補正（直線的なドリフトの補正）を行う実装にとどまる。 なおNTPサーバプログラムを用いてコンピュータの時刻の校正を行う場合、突然『もっともらしい時刻』に校正するのは危険である。サーバ機能を提供しているコンピュータでは、時刻が飛ぶことにより、定時に実行されるサービス（UNIXのcron・atなど）が実行されなくなったり（時計を進める場合）同じサービスが2回実行される（時計を遅らせる場合）ことがあるからである。したがって、ドリフトを調整して時刻を目的の時刻に徐々に近づけていく実装が正しい。 閏秒の扱いNTPプロトコルでは、電波時計の時刻送信フォーマットのように閏秒の扱いも規定されている。閏秒の挿入または削除が行われるという通知は、設定ファイル、参照クロック、リモートサーバのいずれかから受け取る。参照クロックやリモートサーバから受け取る場合は、NTPパケット内の閏秒の警告情報のフィールドが使用される。 警告情報を受け取った側がどう処理するかは、コンピュータプログラムの実装に任される。しかし、削除された1秒に自動起動するサービスがあるかもしれなかったり、外部要因で日付が変わると無効になるライセンスがありえたりするため注意が必要である[35]。 leap smearingと呼ばれる実装では、一秒挿入するのではなく、閏秒の前後20時間をかけて、ゆっくり一秒分の時間を伸ばすことで問題を回避している[36]。この実装は、Google（内部的にも公開NTPサーバー上でも）とAmazon AWSによって使用されている[37]。 実装 下位プロトコル通常、NTPはUDP上で動作する。UDPのポートは123番を使用する。ルータのパケットフィルタの設定でポート123番を通さないようにしている場合は、外部のNTPサーバにアクセスできなくなるので、通すように設定する必要がある リファレンス実装NTPのリファレンス実装は、プロトコルとともに20年以上にわたって継続的に開発されてきた。新しい機能が追加されても、後方互換性が維持されてきた。これには、特にクロックを規律するためのいくつかの繊細なアルゴリズムが含まれており、異なるアルゴリズムを使用しているサーバに同期させると誤動作する可能性がある。このソフトウェアは、パーソナルコンピュータを含むほぼ全てのプラットフォームに移植されている。UNIXではntpdというデーモンとして、Windowsではサービスとして動作する。基準クロックにも対応しており、そのオフセットはリモートサーバと同じようにフィルタリングされ、分析されるが、通常はより頻繁にポーリングされる[1]:15–19。この実装は2017年に検査され、多数の潜在的なセキュリティ問題が発見された[38]。 SNTP→詳細は「Simple Network Time Protocol」を参照
Simple Network Time Protocol (SNTP)は、NTPと同じプロトコルを使用するが、長時間の状態の保存を必要としない、NTPのサブセットの実装である[39]。組み込みシステムや、完全なNTP機能が必要とされないアプリケーションで使用される[40]。 WindowsWindows NTではSMBプロトコルを使ったnet timeコマンドによる時刻同期が可能であったが、これはNTPではなかった。またそれ以前のWindowsでは、サードパーティーのソフトウェアを使用する必要があり、日本では、Windowsが本格的にインターネット対応を開始した1990年代後半に「桜時計」と呼ばれる、サードパーティーによるNTPの実装が有名になった。 Windows 2000以降のWindowsには、コンピュータの時計をNTP サーバに同期させる機能を持つWindows Timeサービス (W32Time)が含まれている[41]。W32Timeは元々ケルベロス認証バージョン5のために実装されたものである。ケルベロス認証では、反射攻撃への対抗として、タイムスタンプに含まれる時間が正確な時間から5分以内である必要があった。 Windows 2000とWindows XPではSNTPのみを実装しており、NTPバージョン3に対してはいくつかの規約に違反している[42]。Windows Server 2003とWindows Vistaからは、フルセットのNTPに準拠した実装となり[43]、GUIで時刻同期を設定することができるようになった。また、有志によってビルドされたWindows向けのntpd/ntpdateも公開されている[44]。 マイクロソフトは、W32Timeは1秒の精度でしか時刻同期を確実に維持できないと声明している[45]。より高い精度が必要な場合は、Windowsの新しいバージョンを使用するか、別のNTP実装を使用することを勧めている[46]。Windows 10とWindows Server 2016では、特定の動作条件の下で1ミリ秒の時間精度の同期に対応している[47][45]。 UNIXなどOpenNTPD2004年、Henning Brauerは、セキュリティに焦点を当てて特権分離設計としたNTPの実装であるOpenNTPDを発表した。これは、OpenBSDユーザのニーズに密着したものである一方で、 既存のNTPサーバとの互換性を保ちつつ、いくつかのプロトコルセキュリティの改善も含まれている。移植版は、Linuxのパッケージリポジトリで入手可能である。 ntimed新しいNTPクライアントであるntimedが、ポール＝ヘニング・カンプによって2014年に開始された[48]。この実装は、リファレンス実装の代替としてLinux Foundationがスポンサーとなっている。リファレンス実装を元にするより、新しい実装をゼロから書いた方が簡単であると判断されたためである。公式にはリリースされていないが、ntimedは確実にクロックを同期させることができる[49]。 NTPsecNTPsecは、リファレンス実装をフォークし、体系的にセキュリティを強化した実装である。フォークポイントは2015年6月で、2014年に発生した危殆化した脆弱性への対応が行われた。最初の正式版は2017年10月にリリースされた[50]。安全ではない機能の削除、時代遅れのハードウェアやUNIXバリアントへの対応の削除により、元のソースコードの75%を削除し、残りの部分を検査を受けやすくした[51]。2017年のコードの検査では、リファレンス実装にはなかった2つを含む8つのセキュリティ問題が検出されたが、元のリファレンス実装に残っていた他の8つの問題の影響を受けることがなかった[52]。 chrony chronyは、Red Hatのディストリビューション[53]にデフォルトで搭載されており、ubuntuのリポジトリでも利用可能である[54]。chronyは、不安定でスリープモードになったり、インターネットに断続的に接続したりするような一般的なコンピュータを対象としている[55]。また、より不安定な環境である仮想マシン用にも設計されている。リソース消費量（コスト）が少ないのが特徴で、NTPだけでなく、Precision Time Protocol(PTP)にも対応している。主なコンポーネントは、コンピュータの起動時に実行されるデーモンであるchronydと、その設定のためのコマンドラインインターフェースであるchronycの2つである。 chronycは非常に安全で、数件の事故があっただけだが[56]、その利点は、不必要な複雑さを避けるためにゼロから書かれたコードの汎用性にある[57]。 chronyはGNU General Public License version 2で利用可能である。1997年にRichard Curnowによって作成され、現在はMiroslav Lichvarによってメンテナンスされている[58]。 MacmacOS においても、標準でntpd/ntpdateが使用されていて、コマンドを意識せずGUIから設定できる。以前のMac OS 9でもNTPクライアントは標準で組み込まれていた。 その他また、ルーターやスイッチングハブなどのネットワーク機器にNTPサーバが搭載される場合がある。もともとは高級なネットワーク機器[注釈 5]に搭載される機能であったが、ネットワーク普及に伴う機器の低価格化により、2000年代後半には民生用のネットワーク機器においてもNTPサーバが搭載されている。 運用と諸問題前述の通りNTPは階層構造を採用しているため、負荷分散が行えるように工夫されている。しかし、NTPと同じく階層構造を採用するDNSではDHCPやPPPによるDNSサーバアドレス配信の仕組みが普及しているのに対し、NTPではDHCPではオプション42として[59][60]、DHCPv6ではオプション56として[61][62]NTPサーバアドレス配信の仕組みが定義されているものの、2024年3月現在ほとんど利用されていない。よって、エンドユーザーは自ネットワーク内のNTPサーバの存在を知ることができず、エンドユーザーが stratum 1 の公開 NTP サーバを使用する傾向がある。結果的に、一つのNTPサーバにアクセスが集中するためサーバの応答性を下げ、配信される時刻の正確性が失われる。 この問題に対する国際的なプロジェクトとして、NTP pool project が存在する。これは、世界全体、あるいは国単位でまとめられたNTPサーバーのリストを用意し、DNSラウンドロビンによってNTPクライアントからのアクセスを振り分けるようにする公開DNSサーバーであり、サーバー名として 0.pool.ntp.org, 1.pool.ntp.org などのように指定すると全世界にあるNTPサーバーからランダムに選ばれたどれかのIPアドレスが返される。大陸別、あるいは国別の地域割りもなされており、たとえば 0.jp.pool.ntp.org や 1.jp.pool.ntp.org を指定すれば、日本国内にあるNTPサーバーのIPアドレスがランダムに返される。0.asia.pool.ntp.org ならアジア地区のNTPサーバーのどれかがランダムに選ばれる。プールされているサーバーのアドレスは、2022年10月現在、全世界で4665、日本国内については44である。なお、このプロジェクトはエンドユーザーからのアクセスを分散することを主目的としているため、プールされているNTPサーバーには、stratum 3や4も含まれている。 Windows や macOS の初期設定サーバは混雑しているため、ISP提供のサーバや、上記のNTPプール、あるいは後述の公開NTPサーバ等に変更すると、より正確な時刻取得が可能になる。 日本では情報通信研究機構 (NICT) が世界最高性能のNTPサーバ (ntp.nict.jp) を2006年6月より一般公開したので、負荷に起因する問題は解決の方向へ向かうと思われる。NICTによれば、世界中のNTPリクエストを合計しても数万リクエスト/秒程度なので、100万リクエスト/秒を扱える新しいシステムでは負荷の問題ではなく知名度の低さが問題としている[63]。 clock.nc.fukuoka-u.ac.jp問題日本では、福岡大学が1993年（平成5年）からNTPサーバを公開しているが、ここを参照するように設定された機器や組み込まれたソフトウェアが非常に多いため[注釈 6]、アクセス集中による過負荷に悩まされていることが、2005年に報告された[64]。契約しているインターネットサービスプロバイダ (ISP) の公開するサーバを利用することで、この問題は解消するので、ISPや研究機関等が加入者向けにサービスするNTPサーバや公開NTPサーバに、今すぐ設定を変更することである。 2017年現在も、福岡大学NTPサーバへのデータトラフィックは過大な状態が続いており、平均180Mbpsに達している[65]。アクセス過多の原因の一つとして、一部メーカーのネットワーク機器にNTPサーバのアドレスがハードコーティングされていることが挙げられている。 ネットワーク機器にアドレスがハードコーティングされた一例として、TP-Link製の無線LAN中継器がある。この機器は、本来の時刻同期の目的ではなくインターネット回線の接続状態を確認するため、福岡大学を含む複数のNTPサーバへ数秒間隔でアクセスする仕様になっていた。TP-Linkからは管理画面を開いている間のみNTPサーバへアクセスするよう、仕様を変更したファームウェアが公開されている[66]。 2017年、福岡大学は同NTPサービスの提供を2018年4月以降に停止する事を発表した[67]。これは、データトラフィックが多すぎるため、大学ネットワーク運用に無駄な費用がかかっている事や、サービス開始当初の1993年はNTPで時刻同期することが研究対象であったが、現在では様々なアプライアンスが販売されているため、NTPの研究として役目を終えたと理由を挙げている。2019年3月12日に2台あるNTPサーバーのうちの1台を停止した[68]。 ウィスコンシン大学-ネットギアNTP問題ネットギア製のルーターがウィスコンシン大学のNTPサーバを参照するようハードコードされていたため、負荷が極度に集中した。以下に問題の経緯を記す。 2003年5月、ウィスコンシン大学に対して平均毎秒4万パケット[注釈 7]のNTPサービスへの接続が行われた。 これに対し大学側はNTP用に公開していたポートを閉じ、悪意あるアクセスは数時間のうちに収まるであろうと考えていた。しかしながら1か月後の2003年6月の時点において、大学側の予想に反するどころかさらに状況は悪化し平均毎秒25万パケットを記録。さらなる調査によって、多くの接続元が1秒毎に問い合わせを行っている事に不審を抱くこととなる。接続元となっている2つの大学に協力を要請。調査結果の中で双方ともにネットギア製のルーターを使用していた事が判明、型番もMR814であると特定された。 同年6月16日、大学側はネットギアのカスタマーサポート宛に電子メールにて状況の報告を行ったが返答がないため直接交渉を行い、19日にネットギアから「開発者によるデバッグ時の設定値の残骸が引き起こしたもの」との説明が大学側に報告され、協力体制が整備された。 2003年8月の時点において、影響を受けた生産台数70万台から行われる最大毎秒70万パケットに及ぶリスクに対して、大学側はルーター使用者に影響がでないよう配慮し、ネットギアからはファームウェアのバージョンアップが提供された。これによりウィスコンシン大学の転送量の増加傾向は弱くなり、同年11月からは減少傾向に転じることとなった。 なお、これらの事件の詳細は、2003年8月21日にウィスコンシン大学のDave Plonkaによりまとめられている[69]。 他に、FreeBSDの有力開発者であるPoul-Henning Kamp(phk)が発見したD-link製ルータの問題や、ダブリンのTardis and Trinity Collegeの問題など、同様の問題が発生している。NTPサーバの誤用・不正使用問題を参照のこと。 脚注注釈
出典
参考文献
関連項目
外部リンク公開NTPサーバ
日本国内
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[icon]](%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Wiki_letter_w_cropped.svg){kind=small}
