[要約] RFC 8633は、ネットワークタイムプロトコル（NTP）のベストカレントプラクティスを提供するものであり、NTPのセキュリティと信頼性の向上を目的としています。
Internet Engineering Task Force (IETF) D. Reilly, Ed.
Request for Comments: 8633 Orolia USA
BCP: 223 H. Stenn
Category: Best Current Practice Network Time Foundation
ISSN: 2070-1721 D. Sibold
PTB
July 2019
Network Time Protocol Best Current Practices
ネットワークタイムプロトコルの現在のベストプラクティス
Abstract
概要
The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.
Network Time Protocol（NTP）は、インターネット上で最も古いプロトコルの1つであり、最初の公開以来広く使用されてきました。このドキュメントは、インターネット上でのNTPサーバーとクライアントの一般的な運用に関するベストプラクティスの集まりです。これには、NTPインフラストラクチャの安定した正確で安全な運用に関する推奨事項が含まれています。このドキュメントは、RFC 5905で説明されているNTPバージョン4を対象としています。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8633.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8633で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General Network Security Best Practices . . . . . . . . . . . 4
2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. NTP Configuration Best Practices . . . . . . . . . . . . . . 5
3.1. Keeping NTP Up to Date . . . . . . . . . . . . . . . . . 5
3.2. Using Enough Time Sources . . . . . . . . . . . . . . . . 5
3.3. Using a Diversity of Reference Clocks . . . . . . . . . . 6
3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 7
3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8
3.7. Leap-Second Handling . . . . . . . . . . . . . . . . . . 8
3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9
4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11
4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
4.4. External Security Protocols . . . . . . . . . . . . . . . 12
5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12
5.1. Minimizing Information Leakage . . . . . . . . . . . . . 12
5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13
5.3. Detection of Attacks through Monitoring . . . . . . . . . 14
5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 15
5.5. Broadcast Mode Only on Trusted Networks . . . . . . . . . 15
5.6. Symmetric Mode Only with Trusted Peers . . . . . . . . . 16
6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16
6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
6.2. Server Configuration . . . . . . . . . . . . . . . . . . 17
7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Best Practices Specific to the Network Time
Foundation Implementation . . . . . . . . . . . . . 23
A.1. Use Enough Time Sources . . . . . . . . . . . . . . . . . 23
A.2. NTP Control and Facility Messages . . . . . . . . . . . . 23
A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. Leap-Second File . . . . . . . . . . . . . . . . . . . . 24
A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 25
A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 25
A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
NTP version 4 (NTPv4) has been widely used since its publication as [RFC5905]. This document is a collection of best practices for the operation of NTP clients and servers.
NTPバージョン4（NTPv4）は、[RFC5905]として公開されて以来、広く使用されています。このドキュメントは、NTPクライアントとサーバーの操作に関するベストプラクティスの集まりです。
The recommendations in this document are intended to help operators distribute time on their networks more accurately and securely. They are intended to apply generally to a broad range of networks. Some specific networks may have higher accuracy requirements that call for additional techniques beyond what is documented here.
このドキュメントの推奨事項は、オペレーターがネットワーク上で時間をより正確かつ安全に配布するのに役立つことを目的としています。それらは一般的に広範囲のネットワークに適用することを意図しています。一部の特定のネットワークには、ここに記載されているものを超える追加の技術を必要とする、より高い精度要件がある場合があります。
Among the best practices covered are recommendations for general network security, time protocol-specific security, and NTP server and client configuration. NTP operation in embedded devices is also covered.
カバーされているベストプラクティスには、一般的なネットワークセキュリティ、時間プロトコル固有のセキュリティ、NTPサーバーとクライアントの構成に関する推奨事項があります。組み込みデバイスでのNTP動作についても説明します。
This document also contains information for protocol implementors who want to develop their own implementations compliant with RFC 5905.
このドキュメントには、RFC 5905に準拠した独自の実装を開発するプロトコル実装者向けの情報も含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Many network attacks rely on modifying the IP source address of a packet to point to a different IP address than the computer from which it originated. UDP-based protocols, such as NTP, are generally more susceptible to spoofing attacks than connection-oriented protocols. NTP control messages can generate a lot of data in response to a small query, which makes it attractive as a vector for distributed denial-of-service attacks (NTP Control messages are discussed further in Section 3.4). One documented instance of such an attack can be found in [DDOS], with further discussion in [IMC14] and [NDSS14].
多くのネットワーク攻撃は、パケットのIP送信元アドレスを変更して、パケットの発信元のコンピューターとは異なるIPアドレスを指すようにします。 NTPなどのUDPベースのプロトコルは、一般に、接続指向のプロトコルよりもスプーフィング攻撃の影響を受けやすくなっています。 NTP制御メッセージは、小さなクエリに応答して大量のデータを生成する可能性があるため、分散型サービス拒否攻撃のベクトルとして魅力的です（NTP制御メッセージについては、セクション3.4で詳しく説明します）。そのような攻撃の文書化されたインスタンスの1つは[DDOS]にあり、[IMC14]と[NDSS14]でさらに議論されています。
BCP 38 [RFC2827] was published in 2000 to provide some level of remediation against address-spoofing attacks. BCP 38 calls for filtering outgoing and incoming traffic to make sure that the source and destination IP addresses are consistent with the expected flow of traffic on each network interface. It is RECOMMENDED that ISPs and large corporate networks implement ingress and egress filtering. More information is available at [BCP38WIKI].
BCP 38 [RFC2827]は2000年に公開され、アドレススプーフィング攻撃に対するある程度の修正を提供します。 BCP 38は、発信および着信IPアドレスが各ネットワークインターフェイスで予想されるトラフィックフローと一致することを確認するために、発信および着信トラフィックをフィルタリングすることを要求します。 ISPと大規模な企業ネットワークは、入力と出力のフィルタリングを実装することをお勧めします。詳細については、[BCP38WIKI]を参照してください。
This section provides best practices for NTP configuration and operation. Application of these best practices that are specific to the Network Time Foundation implementation, including example configuration directives valid at the time of this writing, are compiled in Appendix A.
このセクションでは、NTPの設定と操作のベストプラクティスを提供します。この執筆時点で有効な設定ディレクティブの例を含む、Network Time Foundation実装に固有のこれらのベストプラクティスの適用は、付録Aにまとめられています。
There are multiple versions and implementations of the NTP protocol in use on many different platforms. The practices in this document are meant to apply generally to any implementation of [RFC5905]. NTP users should select an implementation that is actively maintained. Users should keep up to date on any known attacks on their selected implementation and deploy updates containing security fixes as soon as it is practical.
多くの異なるプラットフォームで使用されているNTPプロトコルの複数のバージョンと実装があります。このドキュメントのプラクティスは、[RFC5905]の実装に一般的に適用されることを意図しています。 NTPユーザーは、アクティブに維持されている実装を選択する必要があります。ユーザーは、選択した実装に対する既知の攻撃を最新の状態に保ち、セキュリティ修正が含まれている更新が実用的なものになり次第展開する必要があります。
An NTP implementation that is compliant with [RFC5905] takes the available sources of time and submits this timing data to sophisticated intersection, clustering, and combining algorithms to get the best estimate of the correct time. The description of these algorithms is beyond the scope of this document. Interested readers should read [RFC5905] or the detailed description of NTP in [MILLS2006].
[RFC5905]に準拠したNTP実装は、利用可能な時間ソースを使用して、このタイミングデータを洗練された交差、クラスタリング、および結合アルゴリズムに送信し、正しい時間の最適な見積もりを取得します。これらのアルゴリズムの説明は、このドキュメントの範囲を超えています。興味のある読者は[RFC5905]または[MILLS2006]のNTPの詳細な説明を読んでください。
o If there is only one source of time, the answer is obvious. It may not be a good source of time, but it's the only source that can be considered. Any issue with the time at the source will be passed on to the client.
o 時間のソースが1つしかない場合、答えは明白です。それは良い時間源ではないかもしれませんが、考慮できる唯一の情報源です。ソースの時刻に関する問題はすべてクライアントに渡されます。
o If there are two sources of time and they align well enough, then the best time can be calculated easily. But if one source fails, then the solution degrades to the single-source solution outlined above. And if the two sources don't agree, it will be difficult to know which one is correct without making use of information from outside of the protocol.
o 2つの時間ソースがあり、それらが十分に一致している場合、最適な時間を簡単に計算できます。ただし、1つのソースに障害が発生すると、ソリューションは上記の単一ソースソリューションに低下します。また、2つのソースが一致しない場合、プロトコルの外部からの情報を利用しないと、どちらが正しいかを知ることは困難になります。
o If there are three sources of time, there is more data available to converge on the best calculated time, and this time is more likely to be accurate. And the loss of one of the sources (by becoming unreachable or unusable) can be tolerated. But at that point, the solution degrades to the two-source solution.
o 時間のソースが3つある場合は、計算された最適な時間に収束するために利用できるデータが多く、この時間が正確である可能性が高くなります。また、（到達不能または使用不能になることによる）ソースの1つの損失は許容できます。しかし、その時点で、ソリューションは2ソースソリューションに低下します。
o Having four or more sources of time is better as long as the sources are diverse (Section 3.3). If one of these sources develops a problem, there are still at least three other time sources.
o 発生源が多様である限り（セクション3.3）、4つ以上の発生源がある方が良いでしょう。これらのソースのいずれかで問題が発生した場合でも、他に少なくとも3つのタイムソースがあります。
This analysis assumes that a majority of the servers used in the solution are honest, even if some may be inaccurate. Operators should be aware of the possibility that if an attacker is in control of the network, the time coming from all servers could be compromised.
この分析では、ソリューションで使用されているサーバーの大部分が正直であると想定しています。オペレーターは、攻撃者がネットワークを制御している場合、すべてのサーバーからの時間が危険にさらされる可能性があることに注意する必要があります。
Operators who are concerned with maintaining accurate time SHOULD use at least four independent, diverse sources of time. Four sources will provide sufficient backup in case one source goes down. If four sources are not available, operators MAY use fewer sources, which is subject to the risks outlined above.
正確な時間の維持に関心を持つオペレーターは、少なくとも4つの独立した多様な時間ソースを使用する必要があります。 1つのソースがダウンした場合に備えて、4つのソースで十分なバックアップが提供されます。 4つのソースが利用できない場合、オペレーターはより少ないソースを使用できますが、これは上記で概説したリスクの影響を受けます。
But even with four or more sources of time, systemic problems can happen. One example involves the leap-smearing concept detailed in Section 3.7.1. For several hours before and after the June 2015 leap second, several operators configured their NTP servers with leap smearing while others did not. Many NTP end nodes could not determine an accurate time source because two of their four sources of time gave them consistent UTC/POSIX time, while the other two gave them consistent leap-smeared time. This is just one of many potential causes of disagreement among time sources.
しかし、4つ以上の時間ソースがあっても、システムの問題が発生する可能性があります。 1つの例として、3.7.1節で説明する飛躍的な概念が含まれます。 2015年6月のうるう秒の前後数時間の間、いくつかのオペレーターはNTPサーバーをうるうスミアで設定しましたが、他のオペレーターは設定しませんでした。多くのNTPエンドノードは、4つの時間ソースのうち2つが一貫したUTC / POSIX時間を提供し、他の2つが一貫したうるう時間を与えたため、正確な時間ソースを決定できませんでした。これは、タイムソース間の不一致の多くの潜在的な原因の1つにすぎません。
Operators are advised to monitor all time sources that are in use. If time sources do not generally align, operators are encouraged to investigate the cause and either correct the problems or stop using defective servers. See Section 3.5 for more information.
オペレーターは、使用中のすべてのタイムソースを監視することをお勧めします。タイムソースが一般的に一致しない場合、オペレーターは原因を調査して問題を修正するか、欠陥のあるサーバーの使用を停止することをお勧めします。詳細については、セクション3.5を参照してください。
When using servers with attached hardware reference clocks, it is suggested that different types of reference clocks be used. Having a diversity of sources with independent implementations means that any one issue is less likely to cause a service interruption.
ハードウェア参照クロックが接続されたサーバーを使用する場合、異なるタイプの参照クロックを使用することをお勧めします。独立した実装でソースが多様であることは、1つの問題がサービスの中断を引き起こす可能性が低いことを意味します。
Are all clocks on a network from the same vendor? They may have the same bugs. Even devices from different vendors may not be truly independent if they share common elements. Are they using the same base chipset? Are they all running the same version of firmware? Chipset and firmware bugs can happen, but they can be more difficult to diagnose than application software bugs. When having the correct time is of critical importance, it's ultimately up to operators to ensure that their sources are sufficiently independent, even if they are not under the operator's control.
すべてのクロックは同じベンダーのネットワーク上にありますか？彼らは同じバグがあるかもしれません。異なるベンダーのデバイスでさえ、共通の要素を共有している場合、真に独立しているとは限りません。同じ基本チップセットを使用していますか？それらはすべて同じバージョンのファームウェアを実行していますか？チップセットとファームウェアのバグが発生する可能性がありますが、アプリケーションソフトウェアのバグよりも診断が困難な場合があります。正確な時間を持つことが非常に重要な場合、たとえそれらがオペレーターの制御下にない場合でも、ソースが十分に独立していることを確認するのは最終的にオペレーター次第です。
A systemic problem with time from any satellite navigation service is possible and has happened. Sunspot activity can render a satellite or radio-based time source unusable. Depending on the application requirements, operators may need to consider backup scenarios in the rare circumstance when the satellite system is faulty or unavailable.
衛星航法サービスからの時間に関する体系的な問題が発生する可能性があり、発生しています。太陽黒点の活動により、衛星またはラジオベースのタイムソースが使用できなくなる可能性があります。アプリケーションの要件によっては、衛星システムに障害があるか利用できないというまれな状況で、オペレーターがバックアップシナリオを検討する必要がある場合があります。
Some implementations of NTPv4 provide the NTP control messages (also known as Mode 6 messages). These messages were originally specified in Appendix B of [RFC1305], which defined NTPv3. These messages do not appear in the NTPv4 specification [RFC5905], which obsoletes the NTPv3 specification [RFC1305], but they are still used. At the time of this writing, work is being done to formally document the structure of these control messages for use with NTPv4 in [CTRLMSG].
NTPv4の一部の実装では、NTP制御メッセージ（モード6メッセージとも呼ばれます）が提供されます。これらのメッセージは、NTPv3を定義した[RFC1305]の付録Bで最初に指定されました。これらのメッセージは、NTPv3仕様[RFC1305]を廃止したNTPv4仕様[RFC5905]には表示されませんが、引き続き使用されます。この記事の執筆時点では、[CTRLMSG]のNTPv4で使用するこれらの制御メッセージの構造を正式に文書化する作業が行われています。
NTP control messages are designed to permit monitoring and optionally authenticated control of NTP and its configuration. Used properly, these facilities provide vital debugging and performance information and control. But these facilities can be a vector for amplification attacks when abused. For this reason, it is RECOMMENDED that public-facing NTP servers block NTP control message queries from outside their organization.
NTP制御メッセージは、NTPとその構成の監視と、オプションで認証された制御を許可するように設計されています。これらの機能を適切に使用すると、重要なデバッグおよびパフォーマンス情報と制御が提供されます。しかし、これらの機能は、悪用されたときに増幅攻撃の媒介となる可能性があります。このため、一般に公開されているNTPサーバーは、組織の外部からのNTP制御メッセージクエリをブロックすることをお勧めします。
The ability to use NTP control messages beyond their basic monitoring capabilities SHOULD be limited to authenticated sessions that provide a 'controlkey'. It can also be limited through mechanisms outside of the NTP specification, such as Access Control Lists, that only allow access from approved IP addresses.
基本的な監視機能を超えてNTP制御メッセージを使用する機能は、「controlkey」を提供する認証済みセッションに限定する必要があります（SHOULD）。また、承認されたIPアドレスからのアクセスのみを許可する、アクセス制御リストなどのNTP仕様外のメカニズムによって制限することもできます。
The NTP control message responses are much larger than the corresponding queries. Thus, they can be abused in high-bandwidth DDoS attacks. Section 2.1 gives more information on how to provide protection for this abuse by implementing BCP 38.
NTP制御メッセージの応答は、対応するクエリよりもはるかに大きくなります。したがって、高帯域幅のDDoS攻撃で悪用される可能性があります。セクション2.1は、BCP 38を実装することにより、この虐待に対する保護を提供する方法に関する詳細情報を提供します。
Operators SHOULD use their NTP implementation's remote monitoring capabilities to quickly identify servers that are out of sync and ensure correct functioning of the service. Operators SHOULD also monitor system logs for messages so that problems and abuse attempts can be quickly identified.
オペレーターは、NTP実装のリモート監視機能を使用して、同期していないサーバーをすばやく特定し、サービスが正しく機能するようにする必要があります（SHOULD）。オペレーターはまた、システムログでメッセージを監視して、問題や乱用の試みを迅速に特定できるようにする必要があります（SHOULD）。
If a system starts to receive NTP Reply packets from a remote time server that do not correspond to any requests sent by the system, that can be an indication that an attacker is forging that system's IP address in requests to the remote time server. The goal of this attack is to adversely impact the availability of time to the targeted system whose address is being forged. Based on these forged packets, the remote time server might decide to throttle or rate-limit packets or even stop sending packets to the targeted system.
システムが送信したリクエストに対応しないNTP応答パケットをリモートタイムサーバーから受信し始めた場合は、攻撃者がリモートタイムサーバーへのリクエストでそのシステムのIPアドレスを偽造している可能性があります。この攻撃の目的は、アドレスが偽造されているターゲットシステムの時間の可用性に悪影響を与えることです。これらの偽造されたパケットに基づいて、リモートタイムサーバーは、パケットをスロットルまたはレート制限するか、ターゲットシステムへのパケットの送信を停止することを決定する場合があります。
If a system is a broadcast client and its system log shows that it is receiving early time messages from its server, that is an indication that somebody may be forging packets from a broadcast server (broadcast client and server modes are defined in Section 3 of [RFC5905]).
システムがブロードキャストクライアントであり、そのシステムログにサーバーからアーリータイムメッセージを受信していることが示されている場合は、誰かがブロードキャストサーバーからパケットを偽造している可能性があることを示しています（ブロードキャストクライアントとサーバーのモードは、[ RFC5905]）。
If a server's system log shows messages that indicate it is receiving NTP timestamps that are much earlier than the current system time, then either the system clock is unusually fast or somebody is trying to launch a replay attack against that server.
サーバーのシステムログに、現在のシステム時刻よりはるかに早いNTPタイムスタンプを受信していることを示すメッセージが表示される場合、システムクロックが異常に速いか、誰かがそのサーバーに対して再生攻撃を開始しようとしています。
It only takes a small amount of bandwidth and system resources to synchronize one NTP client, but NTP servers that can service tens of thousands of clients take more resources to run. Network operators and advanced users who want to synchronize their computers MUST only synchronize to servers that they have permission to use.
1つのNTPクライアントを同期するために必要な帯域幅とシステムリソースはごくわずかですが、数万のクライアントにサービスを提供できるNTPサーバーは、実行するのにより多くのリソースを必要とします。コンピューターを同期するネットワークオペレーターと上級ユーザーは、使用する権限があるサーバーのみと同期する必要があります。
The NTP Pool Project is a group of volunteers who have donated their computing and bandwidth resources to freely distribute time from primary time sources to others on the Internet. The time is generally of good quality but comes with no guarantee whatsoever. If you are interested in using this pool, please review their instructions at [POOLUSE].
NTPプールプロジェクトは、コンピューティングリソースと帯域幅リソースを寄付して、プライマリタイムソースからインターネット上の他の時間ソースに時間を自由に配布したボランティアのグループです。時間は一般的に良質ですが、保証はありません。このプールの使用に興味がある場合は、[POOLUSE]で手順を確認してください。
Vendors can obtain their own subdomain that is part of the NTP Pool Project. This offers vendors the ability to safely make use of the time distributed by the pool for their devices. Details are available at [POOLVENDOR].
ベンダーは、NTPプールプロジェクトの一部である独自のサブドメインを取得できます。これにより、ベンダーはプールによってデバイスに割り当てられた時間を安全に利用することができます。詳細については、[POOLVENDOR]をご覧ください。
If there is a need to synchronize many computers, an operator may want to run local NTP servers that are synchronized to the NTP Pool Project. NTP users on that operator's networks can then be synchronized to local NTP servers.
多くのコンピューターを同期する必要がある場合、オペレーターは、NTPプールプロジェクトに同期するローカルNTPサーバーを実行することができます。次に、そのオペレーターのネットワーク上のNTPユーザーをローカルNTPサーバーに同期できます。
UTC is kept in agreement with the Universal Time UT1 [SOLAR] to within +/- 0.9 seconds by the insertion (or possibly deletion) of a leap second. UTC is an atomic time scale, whereas UT1 is based on the rotational rate of the earth. Leap seconds are not introduced at a fixed rate. They are announced by the International Earth Rotation and Reference Systems Service (IERS) in its Bulletin C [IERS] when necessary to keep UTC and UT1 aligned.
UTCは、うるう秒の挿入（または場合によっては削除）によって+/- 0.9秒以内に世界時UT1 [SOLAR]と一致します。 UTCは原子時間スケールですが、UT1は地球の回転速度に基づいています。うるう秒は固定レートでは導入されません。これらは、UTCとUT1の整合を保つために必要なときに、国際地球回転および参照システムサービス（IERS）のBulletin C [IERS]で発表されます。
NTP time is based on the UTC timescale, and the protocol has the capability to broadcast leap-second information. Some global navigation satellite systems (like GPS) or radio transmitters (like DCF77) broadcast leap-second information. If an NTP client is synced to an NTP server that provides leap-second notification, the client will get advance notification of impending leap seconds automatically.
NTP時間はUTCタイムスケールに基づいており、プロトコルにはうるう秒情報をブロードキャストする機能があります。一部のグローバルナビゲーション衛星システム（GPSなど）または無線送信機（DCF77など）は、うるう秒情報をブロードキャストします。 NTPクライアントがうるう秒通知を提供するNTPサーバーに同期されている場合、クライアントは自動的にうるう秒の事前通知を受け取ります。
Since the length of the UT1 day generally slowly increases [SOLAR], all leap seconds that have been introduced since the practice started in 1972 have been positive leap seconds, where a second is added to UTC. NTP also supports a negative leap second, where a second is removed from UTC if it ever becomes necessary.
UT1の日数は通常ゆっくりと増加するため[SOLAR]、1972年に練習が開始されてから導入されたすべてのうるう秒は、正のうるう秒であり、UTCに1秒が追加されます。 NTPは負のうるう秒もサポートしています。この場合、秒が必要になった場合はUTCから削除されます。
While earlier versions of NTP contained some ambiguity regarding when a leap second broadcast by a server should be applied by a client, RFC 5905 is clear that leap seconds are only applied on the last day of a month. However, because some older clients may apply it at the end of the current day, it is RECOMMENDED that NTP servers wait until the last day of the month before broadcasting leap seconds. Doing this will prevent older clients from applying a leap second at the wrong time. When implementing this recommendation, operators should ensure that clients are not configured to use polling intervals greater than 24 hours so the leap-second notification is not missed.
以前のバージョンのNTPには、サーバーによるうるう秒ブロードキャストをクライアントがいつ適用するべきかに関する曖昧さが含まれていましたが、RFC 5905は、うるう秒が月の最終日にのみ適用されることを明確にしています。ただし、一部の古いクライアントは当日の終わりにそれを適用する可能性があるため、うるう秒をブロードキャストする前に、NTPサーバーが月の最終日まで待機することをお勧めします。これにより、古いクライアントがうるう秒を間違ったタイミングで適用するのを防ぐことができます。この推奨事項を実装する場合、オペレーターは、うるう秒の通知を見逃さないように、クライアントが24時間を超えるポーリング間隔を使用するように構成されていないことを確認する必要があります。
In circumstances where an NTP server is not receiving leap-second information from an automated source, certain organizations maintain files that are updated every time a new leap second is announced:
NTPサーバーが自動ソースからうるう秒情報を受信していない状況では、特定の組織は、新しいうるう秒が発表されるたびに更新されるファイルを保持しています。
NIST: <ftp://time.nist.gov/pub/leap-seconds.list>
US Navy (maintains GPS Time):
<ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list>
IERS (announces leap seconds):
<https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>
Some NTP installations make use of a technique called leap smearing. With this method, instead of introducing an extra second (or eliminating a second) in a leap-second event, NTP time is adjusted in small increments over a comparably large window of time (called the smear interval) around the leap-second event. The smear interval should be large enough for the time to be adjusted at a low rate, so that clients will follow the smeared time without objecting. Periods ranging from two to twenty-four hours have been used successfully. During the adjustment window, all the NTP clients' times may be offset from UTC by as much as a full second, depending on the implementation. However, all clients will generally agree on what time they think it is.
一部のNTPインストールでは、うるうスミアと呼ばれる手法を利用しています。この方法では、うるう秒イベントで余分な1秒を導入する（または1秒を削除する）代わりに、うるう秒イベントの周りの比較的大きな時間枠（スミア間隔と呼ばれます）にわたってNTP時間を少しずつ調整します。塗抹の間隔は、時間を低速で調整するのに十分な長さである必要があります。これにより、クライアントは塗抹された時間に反対することなく追跡できます。 2時間から24時間の範囲の期間が正常に使用されています。調整ウィンドウでは、実装によっては、すべてのNTPクライアントの時間がUTCから1秒もずれる場合があります。ただし、すべてのクライアントは、通常、それが何時であるかについて同意します。
The purpose of leap smearing is to enable systems that don't deal with the leap-second event properly to function consistently, at the expense of fidelity to UTC during the smear window. During a standard leap-second event, a minute will have 61 (or possibly 59) seconds, and some applications (and even some OSs) are known to have problems with that.
うるうスミアの目的は、うるう秒イベントを適切に処理しないシステムが一貫して機能できるようにすることですが、スミアウィンドウ中のUTCへの忠実度は犠牲になります。標準のうるう秒イベントの場合、1分は61秒（場合によっては59秒）になり、一部のアプリケーション（さらには一部のOS）で問題が発生することがわかっています。
Operators who have legal obligations or other strong requirements to be synchronized with UTC or civil time SHOULD NOT use leap smearing because the distributed time cannot be guaranteed to be traceable to UTC during the smear interval.
UTCまたは市民時間と同期する法的義務またはその他の強い要件を持つオペレーターは、うるう塗抹法を使用してはなりません。これは、塗抹間隔中の分散時間はUTCに追跡可能であることを保証できないためです。
Clients that are connected to leap-smearing servers MUST NOT apply the standard NTP leap-second handling. These clients must never have a leap-second file loaded, and the smearing servers must never advertise to clients for which a leap second is pending.
うるうサーバーを接続するクライアントは、標準のNTPうるう秒処理を適用してはなりません（MUST NOT）。これらのクライアントにはうるう秒ファイルがロードされてはならず、スミアサーバーはうるう秒が保留されているクライアントにアドバタイズしてはなりません。
Any use of leap-smearing servers should be limited to within a single, well-controlled environment. Leap smearing MUST NOT be used for public-facing NTP servers, as they will disagree with non-smearing servers (as well as UTC) during the leap smear interval, and there is no standardized way for a client to detect that a server is using leap smearing. However, be aware that some public-facing servers may be configured this way in spite of this guidance.
うるうサーバーを使用する場合は、適切に制御された単一の環境内に限定する必要があります。うるうスメアリングは、うるうスメア間隔中に非スミアサーバー（およびUTC）と一致しないため、サーバーが使用していることをクライアントが検出するための標準化された方法がないため、公衆向けNTPサーバーには使用しないでください。飛沫塗抹。ただし、このガイダンスにもかかわらず、一部の公開サーバーはこのように構成されている場合があることに注意してください。
System administrators are advised to be aware of impending leap seconds and how the servers (inside and outside their organization) they are using deal with them. Individual clients MUST NOT be configured to use a mixture of smeared and non-smeared servers. If a client uses smeared servers, the servers it uses must all have the same leap smear configuration.
システム管理者は、差し迫ったうるう秒と、使用しているサーバー（組織の内部および外部）がサーバーをどのように処理するかに注意することをお勧めします。個々のクライアントは、塗抹されたサーバーと塗抹されていないサーバーの混合を使用するように構成してはなりません。クライアントがスミアサーバーを使用する場合、使用するサーバーはすべて同じうるうスミア構成でなければなりません。
In the standard configuration, NTP packets are exchanged unprotected between client and server. An adversary that is able to become a man in the middle is therefore able to drop, replay, or modify the content of the NTP packet, which leads to degradation of the time synchronization or transmission of false time information. A threat analysis for time-synchronization protocols is given in [RFC7384].
標準構成では、NTPパケットはクライアントとサーバー間で保護されずに交換されます。したがって、中間者になることができる敵は、NTPパケットの内容をドロップ、再生、または変更することができ、これにより、時刻同期の低下または誤った時刻情報の送信が発生します。時間同期プロトコルの脅威分析は、[RFC7384]で提供されています。
NTP provides two internal security mechanisms to protect the authenticity and integrity of the NTP packets. Both measures protect the NTP packet by means of a Message Authentication Code (MAC). Neither of them encrypts the NTP's payload because this payload information is not considered to be confidential.
NTPは、NTPパケットの信頼性と整合性を保護する2つの内部セキュリティメカニズムを提供します。どちらの方法も、メッセージ認証コード（MAC）を使用してNTPパケットを保護します。このペイロード情報は機密情報と見なされないため、どちらもNTPのペイロードを暗号化しません。
This approach applies a symmetric key for the calculation of the MAC, which protects the authenticity and integrity of the exchanged packets for an association. NTP does not provide a mechanism for the exchange of keys between the associated nodes. Therefore, for each association, keys MUST be exchanged securely by external means, and they MUST be protected from disclosure. It is RECOMMENDED that each association be protected by its own unique key. It is RECOMMENDED that participants agree to refresh keys periodically. However, NTP does not provide a mechanism to assist in doing so. Each communication partner will need to keep track of its keys in its own local key storage.
このアプローチは、MACの計算に対称キーを適用し、アソシエーションで交換されるパケットの信頼性と整合性を保護します。 NTPは、関連するノード間で鍵を交換するメカニズムを提供しません。したがって、関連付けごとに、鍵は外部の手段によって安全に交換されなければならず（MUST）、それらは開示から保護されなければなりません（MUST）。各関連付けを独自の一意のキーで保護することをお勧めします。参加者が定期的にキーを更新することに同意することをお勧めします。ただし、NTPはそのためのメカニズムを提供していません。各通信パートナーは、独自のローカルキーストレージでキーを追跡する必要があります。
[RFC5905] specifies using the MD5 hash algorithm for calculation of the MAC, but other algorithms may be supported as well. The MD5 hash is now considered to be too weak and unsuitable for cryptographic usage. [RFC6151] has more information on the algorithm's weaknesses. Implementations will soon be available based on AES-128-CMAC [RFC8573], and users SHOULD use that when it is available.
[RFC5905]は、MACの計算にMD5ハッシュアルゴリズムを使用することを指定していますが、他のアルゴリズムもサポートされている場合があります。 MD5ハッシュは現在、弱すぎ、暗号の使用には適さないと見なされています。 [RFC6151]には、アルゴリズムの弱点に関する詳細情報があります。実装は、AES-128-CMAC [RFC8573]に基づいてまもなく利用可能になり、ユーザーは、利用可能になったときにそれを使用する必要があります。
Some implementations store the key in clear text. Therefore, it MUST only be readable by the NTP process.
一部の実装では、キーをクリアテキストで格納します。したがって、NTPプロセスでのみ読み取り可能でなければなりません。
An NTP client has to be able to link a key to a particular server in order to establish a protected association. This linkage is implementation specific. Once applied, a key will be trusted until the link is removed.
NTPクライアントは、保護された関連付けを確立するために、キーを特定のサーバーにリンクできる必要があります。このリンケージは実装固有です。適用されると、リンクが削除されるまでキーは信頼されます。
[RFC5906] specifies the Autokey protocol. It was published in 2010 to provide automated key management and authentication of NTP servers. However, security researchers have identified vulnerabilities [AUTOKEY] in the Autokey protocol.
[RFC5906]はAutokeyプロトコルを指定します。 2010年に公開され、NTPサーバーの自動キー管理と認証を提供します。ただし、セキュリティ研究者は、Autokeyプロトコルの脆弱性[AUTOKEY]を特定しています。
Autokey SHOULD NOT be used.
Autokeyは使用しないでください。
Work is in progress on an enhanced replacement for Autokey. Refer to [NTSFORNTP] for more information.
Autokeyの強化された代替品の作業が進行中です。詳細については、[NTSFORNTP]を参照してください。
If applicable, external security protocols such as IPsec and MACsec can be applied to enhance the integrity and authenticity protection of NTP time-synchronization packets. Usage of such external security protocols can decrease time-synchronization performance [RFC7384]. Therefore, operators are advised to carefully evaluate whether the decreased time-synchronization performance meets their specific timing requirements.
該当する場合は、IPsecやMACsecなどの外部セキュリティプロトコルを適用して、NTP時間同期パケットの整合性と信頼性保護を強化できます。このような外部セキュリティプロトコルを使用すると、時間同期のパフォーマンスが低下する可能性があります[RFC7384]。したがって、オペレーターは、減少した時間同期パフォーマンスが特定のタイミング要件を満たしているかどうかを慎重に評価することをお勧めします。
Note that none of the security measures described in Section 4 can prevent packet delay manipulation attacks on NTP. Such delay attacks can target time-synchronization packets sent as clear text or even within an encrypted tunnel. These attacks are described further in Section 3.2.6 of [RFC7384].
セクション4で説明されているセキュリティ対策は、NTPへのパケット遅延操作攻撃を防ぐことができないことに注意してください。このような遅延攻撃は、クリアテキストまたは暗号化されたトンネル内で送信された時間同期パケットを標的にすることができます。これらの攻撃については、[RFC7384]のセクション3.2.6で詳しく説明しています。
This section lists some general NTP security practices, but these issues may (or may not) have been mitigated in particular versions of particular implementations. Contact the maintainers of the relevant implementation for more information.
このセクションでは、一般的なNTPセキュリティプラクティスをいくつか示しますが、これらの問題は、特定の実装の特定のバージョンで軽減されている場合とそうでない場合があります。詳細については、関連する実装のメンテナに連絡してください。
The base NTP packet leaks important information (including reference ID and reference time) that may be used in attacks [NDSS16] [CVE-2015-8138] [CVE-2016-1548]. A remote attacker can learn this information by sending mode 3 queries to a target system and inspecting the fields in the mode 4 response packet. NTP control queries also leak important information (including reference ID, expected origin timestamp, etc.) that may be used in attacks [CVE-2015-8139]. A remote attacker can learn this information by sending control queries to a target system and inspecting the leaked information in the response.
ベースNTPパケットは、攻撃で使用される可能性のある重要な情報（参照IDと参照時間を含む）を漏洩します[NDSS16] [CVE-2015-8138] [CVE-2016-1548]リモートの攻撃者は、モード3のクエリをターゲットシステムに送信し、モード4の応答パケットのフィールドを検査することで、この情報を知ることができます。 NTP制御クエリは、攻撃で使用される可能性がある重要な情報（参照ID、予想される発生元のタイムスタンプなど）もリークします[CVE-2015-8139]リモートの攻撃者は、制御クエリをターゲットシステムに送信し、応答で漏洩した情報を検査することにより、この情報を知ることができます。
As such, mechanisms outside of the NTP protocol, such as Access Control Lists, SHOULD be used to limit the exposure of this information to allowed IP addresses and keep it from remote attackers not on the list. Hosts SHOULD only respond to NTP control queries from authorized parties.
そのため、アクセス制御リストなど、NTPプロトコルの外部のメカニズムを使用して、この情報の公開を許可されたIPアドレスに制限し、リストにないリモートの攻撃者からの情報を保持する必要があります。ホストは、許可された関係者からのNTP制御クエリにのみ応答する必要があります（SHOULD）。
An NTP client that does not provide time on the network can additionally log and drop incoming mode 3 timing queries from unexpected sources. Note well that the easiest way to monitor the status of an NTP instance is to send it a mode 3 query, so it may not be desirable to drop all mode 3 queries. As an alternative, operators SHOULD either filter mode 3 queries from outside their networks or make sure mode 3 queries are allowed only from trusted systems or networks.
ネットワークに時間を提供しないNTPクライアントは、予期しないソースからの着信モード3タイミングクエリをさらにログに記録してドロップできます。 NTPインスタンスのステータスを監視する最も簡単な方法は、それにモード3クエリを送信することです。そのため、すべてのモード3クエリを削除することは望ましくない場合があります。別の方法として、オペレーターはネットワーク外部からのモード3クエリをフィルターするか、信頼できるシステムまたはネットワークからのみモード3クエリが許可されるようにする必要があります。
A "leaf-node host" is a host that uses NTP solely for the purpose of adjusting its own system time. Such a host is not expected to provide time to other hosts and relies exclusively on NTP's basic mode to take time from a set of servers (that is, the host sends mode 3 queries to its servers and receives mode 4 responses from these servers containing timing information.) To minimize information leakage, leaf-node hosts SHOULD drop all incoming NTP packets except mode 4 response packets that come from known sources. An exception to this can be made if a leaf-node host is being actively monitored, in which case incoming packets from the monitoring server can be allowed.
「リーフノードホスト」とは、自身のシステム時刻を調整する目的でのみNTPを使用するホストです。このようなホストは、他のホストに時間を提供することは期待されておらず、NTPの基本モードにのみ依存してサーバーのセットから時間を費やします（つまり、ホストはモード3クエリをサーバーに送信し、タイミングを含むこれらのサーバーからモード4応答を受信します情報漏えいを最小限に抑えるため、リーフノードホストは、既知のソースからのモード4応答パケットを除くすべての着信NTPパケットをドロップする必要があります（SHOULD）。これに対する例外は、リーフノードホストがアクティブに監視されている場合に行うことができます。その場合、監視サーバーからの着信パケットを許可できます。
Please refer to [DATAMIN] for more information.
詳細については、[DATAMIN]を参照してください。
[RFC5905] says NTP clients should not accept time shifts greater than the panic threshold. Specifically, RFC 5905 says "PANIC means the offset is greater than the panic threshold PANICT (1000 s) and SHOULD cause the program to exit with a diagnostic message to the system log."
[RFC5905]は、NTPクライアントがパニックしきい値より大きいタイムシフトを受け入れてはならないと述べています。具体的には、RFC 5905は、「パニックはオフセットがパニックしきい値PANICT（1000秒）より大きいことを意味し、システムログへの診断メッセージを表示してプログラムを終了させる必要があります（SHOULD）。」
However, this behavior can be exploited by attackers as described in [NDSS16] when the following two conditions hold:
ただし、この動作は、[NDSS16]で説明されているように、次の2つの条件が満たされた場合に攻撃者によって悪用される可能性があります。
1. The operating system automatically restarts the NTP client when it quits. Modern UNIX and UNIX-like operating systems are replacing traditional init systems with process supervisors, such as systemd, which can be configured to automatically restart any daemons that quit. This behavior is the default in CoreOS and Arch Linux. As of the time of this writing, it appears likely to become the default behavior in other systems as they migrate legacy init scripts to process supervisors such as systemd.
1. オペレーティングシステムは、終了時にNTPクライアントを自動的に再起動します。最近のUNIXおよびUNIXに似たオペレーティングシステムは、従来のinitシステムを、終了したデーモンを自動的に再起動するように構成できるsystemdなどのプロセス監視プログラムに置き換えています。この動作は、CoreOSおよびArch Linuxのデフォルトです。これを書いている時点では、他のシステムがsystemdなどのスーパーバイザーを処理するためにレガシーinitスクリプトを移行するため、それがデフォルトの動作になる可能性があります。
2. The NTP client is configured to ignore the panic threshold on all restarts.
2. NTPクライアントは、すべての再起動でパニックしきい値を無視するように構成されています。
In such cases, if the attacker can send the target an offset that exceeds the panic threshold, the client will quit. Then, when it restarts, it ignores the panic threshold and accepts the attacker's large offset.
このような場合、攻撃者がパニックしきい値を超えるオフセットをターゲットに送信できると、クライアントは終了します。その後、再起動すると、パニックしきい値を無視し、攻撃者の大きなオフセットを受け入れます。
Operators need to be aware that when operating with the above two conditions, the panic threshold offers no protection from attacks. The natural solution is not to run hosts with these conditions.
オペレーターは、上記の2つの条件で操作する場合、パニックしきい値は攻撃からの保護を提供しないことに注意する必要があります。自然な解決策は、これらの条件でホストを実行しないことです。
Specifically, operators SHOULD NOT ignore the panic threshold in all cold-start situations unless sufficient oversight and checking is in place to make sure that this type of attack cannot happen.
特に、このタイプの攻撃が発生しないことを確認するために十分な監視とチェックが行われていない限り、オペレーターはすべてのコールドスタート状況でパニックしきい値を無視してはなりません。
As an alternative, the following steps MAY be taken by operators to mitigate the risk of attack:
別の方法として、攻撃のリスクを軽減するために、オペレーターは次の手順を実行してもよい（MAY）。
o Monitor the NTP system log to detect when the NTP daemon quit due to a panic event, as this could be a sign of an attack.
o NTPシステムログを監視して、パニックイベントが原因でNTPデーモンが終了したことを検出します。これは攻撃の兆候である可能性があるためです。
o Request manual intervention when a timestep larger than the panic threshold is detected.
o パニックしきい値より大きいタイムステップが検出された場合は、手動介入を要求します。
o Configure the ntp client to only ignore the panic threshold in a cold-start situation.
o コールドスタートの状況でパニックしきい値のみを無視するようにntpクライアントを構成します。
o Increase the minimum number of servers required before the NTP client adjusts the system clock. This will make the NTP client wait until enough trusted sources of time agree before declaring the time to be correct.
o NTPクライアントがシステムクロックを調整する前に必要なサーバーの最小数を増やします。これにより、NTPクライアントは、時刻が正しいことを宣言する前に、十分な信頼できる発信元が同意するまで待機します。
In addition, the following steps SHOULD be taken by those who implement the NTP protocol:
また、NTPプロトコルを実装するユーザーは、次の手順を実行する必要があります。
o Prevent the NTP daemon from taking time steps that set the clock to a time earlier than the compile date of the NTP daemon.
o NTPデーモンが、NTPデーモンのコンパイル日付よりも前の時刻にクロックを設定するタイムステップを実行しないようにします。
o Prevent the NTP daemon from putting 'INIT' in the reference ID of its NTP packets upon initializing. This will make it more difficult for attackers to know when the daemon reboots.
o 初期化時にNTPデーモンがNTPパケットの参照IDに「INIT」を入れないようにします。これにより、デーモンがいつ再起動するかを攻撃者が知るのが困難になります。
Operators SHOULD monitor their NTP instances to detect attacks. Many known attacks on NTP have particular signatures. Common attack signatures include:
オペレーターは、NTPインスタンスを監視して攻撃を検出する必要があります（SHOULD）。 NTPに対する多くの既知の攻撃には特定のシグネチャがあります。一般的な攻撃シグネチャは次のとおりです。
1. Bogus packets - A packet whose origin timestamp does not match the value that is expected by the client.
1. 偽のパケット-元のタイムスタンプがクライアントが予期する値と一致しないパケット。
2. Zero origin packet - A packet with an origin timestamp set to zero [CVE-2015-8138].
2. ゼロオリジンパケット-オリジンタイムスタンプがゼロに設定されたパケット[CVE-2015-8138]。
3. A packet with an invalid cryptographic MAC.
3. 無効な暗号化MACを持つパケット。
The observation of many such packets could indicate that the client is under attack.
このような多くのパケットの観察は、クライアントが攻撃を受けていることを示している可能性があります。
The "Kiss-o'-Death" (KoD) packet includes a rate-management mechanism where a server can tell a misbehaving client to reduce its query rate. KoD packets in general (and the RATE packet in particular) are defined in Section 7.4 of [RFC5905]. It is RECOMMENDED that all NTP devices respect these packets and back off when asked to do so by a server. This is even more important for an embedded device, which may not have an exposed control interface for NTP.
"Kiss-o'-Death"（KoD）パケットには、サーバーが誤動作しているクライアントにクエリレートを下げるように指示できるレート管理メカニズムが含まれています。 KoDパケット一般（および特にRATEパケット）は、[RFC5905]のセクション7.4で定義されています。すべてのNTPデバイスはこれらのパケットを尊重し、サーバーから要求された場合はバックオフすることをお勧めします。これは、NTPの制御インターフェイスが公開されていない可能性がある組み込みデバイスではさらに重要です。
That said, a client MUST only accept a KoD packet if it has a valid origin timestamp. Once a RATE packet is accepted, the client should increase its poll interval value (thus decreasing its polling rate) to a reasonable maximum. This maximum can vary by implementation but should not exceed a poll interval value of 13 (two hours). The mechanism to determine how much to increase the poll interval value is undefined in [RFC5905]. If the client uses the poll interval value sent by the server in the RATE packet, it MUST NOT simply accept any value. Using large interval values may create a vector for a denial-of-service attack that causes the client to stop querying its server [NDSS16].
つまり、クライアントは、有効なオリジンタイムスタンプがある場合にのみKoDパケットを受け入れる必要があります。 RATEパケットが受け入れられると、クライアントはポーリング間隔の値を増やして（したがって、ポーリングレートを減らして）、妥当な最大値にする必要があります。この最大値は実装によって異なる場合がありますが、ポーリング間隔の値13（2時間）を超えてはなりません。ポーリング間隔の値をどれだけ増やすかを決定するメカニズムは、[RFC5905]で定義されていません。クライアントがRATEパケットでサーバーから送信されたポーリング間隔値を使用する場合、それは単に値を受け入れてはなりません（MUST NOT）。間隔の値を大きくすると、サービス拒否攻撃のベクトルが作成され、クライアントがサーバーへのクエリを停止する可能性があります[NDSS16]。
The KoD rate-management mechanism relies on clients behaving properly in order to be effective. Some clients ignore the RATE packet entirely, and other poorly implemented clients might unintentionally increase their poll rate and simulate a denial-of-service attack. Server administrators are advised to be prepared for this and take measures outside of the NTP protocol to drop packets from misbehaving clients when these clients are detected.
KoDレート管理メカニズムは、効果を上げるためにクライアントが適切に動作することに依存しています。一部のクライアントはRATEパケットを完全に無視し、他の適切に実装されていないクライアントは、意図せずにポーリングレートを上げて、サービス拒否攻撃をシミュレートする場合があります。サーバー管理者は、これに備えて、NTPプロトコルの外で、クライアントが検出されたときに動作が不正なクライアントからパケットをドロップするように対策を講じることをお勧めします。
Kiss-o'-Death (KoD) packets can be used in denial-of-service attacks. Thus, the observation of even just one RATE packet with a high poll value could be sign that the client is under attack. And KoD packets are commonly accepted even when not cryptographically authenticated, which increases the risk of denial-of-service attacks.
Kiss-o'-Death（KoD）パケットは、サービス拒否攻撃で使用できます。したがって、ポーリング値が高いRATEパケットが1つでも見られる場合は、クライアントが攻撃を受けていることを示している可能性があります。また、KoDパケットは暗号で認証されていない場合でも一般的に受け入れられるため、サービス拒否攻撃のリスクが高まります。
Per [RFC5905], NTP's broadcast mode is authenticated using symmetric key cryptography. The broadcast server and all its broadcast clients share a symmetric cryptographic key, and the broadcast server uses this key to append a MAC to the broadcast packets it sends.
[RFC5905]に従い、NTPのブロードキャストモードは対称キー暗号化を使用して認証されます。ブロードキャストサーバーとそのすべてのブロードキャストクライアントは対称暗号化キーを共有し、ブロードキャストサーバーはこのキーを使用して、送信するブロードキャストパケットにMACを追加します。
Importantly, all broadcast clients that listen to this server have to know the cryptographic key. This means that any client can use this key to send valid broadcast messages that look like they come from the broadcast server. Thus, a rogue broadcast client can use its knowledge of this key to attack the other broadcast clients.
重要なことに、このサーバーをリッスンするすべてのブロードキャストクライアントは、暗号化キーを知っている必要があります。つまり、すべてのクライアントがこのキーを使用して、ブロードキャストサーバーから送信されたように見える有効なブロードキャストメッセージを送信できます。したがって、不正なブロードキャストクライアントは、このキーの知識を使用して他のブロードキャストクライアントを攻撃できます。
For this reason, an NTP broadcast server and all its clients have to trust each other. Broadcast mode SHOULD only be run from within a trusted network.
このため、NTPブロードキャストサーバーとそのすべてのクライアントは相互に信頼する必要があります。ブロードキャストモードは、信頼できるネットワーク内からのみ実行する必要があります（SHOULD）。
In symmetric mode, two peers, Alice and Bob, can both push and pull synchronization to and from each other using either ephemeral symmetric passive (mode 2) or persistent symmetric active (NTP mode 1) packets. The persistent association is preconfigured and initiated at the active peer but is not preconfigured at the passive peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob mobilizes a new ephemeral association if he does not have one already. This is a security risk for Bob because an arbitrary attacker can attempt to change Bob's time by asking Bob to become its symmetric passive peer.
対称モードでは、2つのピアAliceとBobは、一時対称パッシブ（モード2）または永続対称アクティブ（NTPモード1）パケットを使用して、相互に同期をプッシュおよびプルできます。永続的な関連付けは、アクティブピアで事前設定および開始されますが、パッシブピア（ボブ）では事前設定されていません。アリスからモード1のNTPパケットを受信すると、ボブは新しい一時的関連付けをまだ持っていなければ、それを動員します。これはボブにとってセキュリティリスクです。任意の攻撃者がボブに対称パッシブピアになるように依頼することで、ボブの時間を変更しようとする可能性があるためです。
For this reason, a host SHOULD only allow symmetric passive associations to be established with trusted peers. Specifically, a host SHOULD require each of its symmetric passive associations to be cryptographically authenticated. Each symmetric passive association SHOULD be authenticated under a different cryptographic key.
このため、ホストは、信頼できるピアとの対称パッシブアソシエーションの確立のみを許可する必要があります（SHOULD）。具体的には、ホストは、その対称パッシブアソシエーションのそれぞれが暗号で認証されることを必要とします（SHOULD）。各対称パッシブアソシエーションは、異なる暗号化キーの下で認証される必要があります（SHOULD）。
As computing becomes more ubiquitous, there will be many small embedded devices that require accurate time. These devices may not have a persistent battery-backed clock, so using NTP to set the correct time on power-up may be critical for proper operation. These devices may not have a traditional user interface, but if they connect to the Internet, they will be subject to the same security threats as traditional deployments.
コンピューティングがよりユビキタスになるにつれて、正確な時間を必要とする多くの小さな組み込みデバイスがあります。これらのデバイスは、バッテリーでバックアップされた永続的なクロックを備えていない場合があるため、NTPを使用して電源投入時に正しい時刻を設定することが、適切な動作にとって重要になる場合があります。これらのデバイスには従来のユーザーインターフェイスがない場合がありますが、インターネットに接続すると、従来の展開と同じセキュリティ上の脅威にさらされます。
Vendors of embedded devices are advised to pay attention to the current state of protocol security issues and bugs in their chosen implementation because their customers don't have the ability to update their NTP implementation on their own. Those devices may have a single firmware upgrade, provided by the manufacturer, that updates all capabilities at once. This means that the vendor assumes the responsibility of making sure their devices have an up-to-date and secure NTP implementation.
組み込みデバイスのベンダーは、顧客が自分でNTP実装を更新することができないため、選択した実装のプロトコルセキュリティの問題とバグの現状に注意を払うことをお勧めします。これらのデバイスには、製造元が提供する単一のファームウェアアップグレードがあり、すべての機能を一度に更新できます。これは、ベンダーがデバイスに最新の安全なNTP実装を確実に実装する責任を負うことを意味します。
Vendors of embedded devices SHOULD include the ability to update the list of NTP servers used by the device.
組み込みデバイスのベンダーは、デバイスが使用するNTPサーバーのリストを更新する機能を含める必要があります（SHOULD）。
There is a catalog of NTP server abuse incidents, some of which involve embedded devices, on the Wikipedia page for NTP Server Misuse and Abuse [MISUSE].
NTPサーバーの悪用と乱用[MISUSE]のWikipediaページに、NTPサーバーの悪用インシデントのカタログ（一部は組み込みデバイスに関連しています）があります。
Vendors of embedded devices with preconfigured NTP servers need to carefully consider which servers to use. There are several public-facing NTP servers available, but they may not be prepared to service requests from thousands of new devices on the Internet. Vendors MUST only preconfigure NTP servers that they have permission to use.
NTPサーバーが事前に構成されている組み込みデバイスのベンダーは、使用するサーバーを慎重に検討する必要があります。公開されているNTPサーバーはいくつかありますが、インターネット上の何千もの新しいデバイスからの要求に対応する準備が整っていない場合があります。ベンダーは、使用を許可されているNTPサーバーのみを事前設定する必要があります。
Vendors are encouraged to invest resources into providing their own time servers for their devices to connect to. This may be done through the NTP Pool Project, as documented in Section 3.6.
ベンダーは、デバイスを接続するための独自のタイムサーバーを提供するためにリソースを投資することをお勧めします。これは、セクション3.6で説明されているように、NTPプールプロジェクトを通じて行うことができます。
Vendors should read [RFC4085], which advises against embedding globally routable IP addresses in products and offers several better alternatives.
ベンダーは[RFC4085]を読む必要があります。これは、グローバルにルーティング可能なIPアドレスを製品に埋め込むことを推奨せず、いくつかのより良い代替案を提供します。
Anycast is described in BCP 126 [RFC4786] (see also [RFC7094]). With anycast, a single IP address is assigned to multiple servers, and routers direct packets to the closest active server.
エニーキャストはBCP 126 [RFC4786]で説明されています（[RFC7094]も参照）。エニーキャストでは、単一のIPアドレスが複数のサーバーに割り当てられ、ルーターは最も近いアクティブサーバーにパケットを転送します。
Anycast is often used for Internet services at known IP addresses, such as DNS. Anycast can also be used in large organizations to simplify the configuration of many NTP clients. Each client can be configured with the same NTP server IP address, and a pool of anycast servers can be deployed to service those requests. New servers can be added to or taken from the pool, and other than a temporary loss of service while a server is taken down, these additions can be transparent to the clients.
エニーキャストは、DNSなどの既知のIPアドレスでインターネットサービスによく使用されます。エニーキャストは、多くのNTPクライアントの構成を簡略化するために大規模な組織で使用することもできます。各クライアントは、同じNTPサーバーのIPアドレスで構成でき、エニーキャストサーバーのプールを展開して、これらの要求にサービスを提供できます。新しいサーバーをプールに追加したり、プールから取得したりできます。サーバーが停止している間、サービスが一時的に失われるほか、これらの追加はクライアントに透過的です。
Note well that using a single anycast address for NTP presents its own potential issues. It means each client will likely use a single time server source. A key element of a robust NTP deployment is each client using multiple sources of time. With multiple time sources, a client will analyze the various time sources, select good ones, and disregard poor ones. If a single anycast address is used, this analysis will not happen. This can be mitigated by creating multiple, separate anycast pools so clients can have multiple sources of time while still gaining the configuration benefits of the anycast pools.
NTPに単一のエニーキャストアドレスを使用すると、潜在的な問題が発生することに注意してください。これは、各クライアントが単一のタイムサーバーソースを使用する可能性が高いことを意味します。堅牢なNTP展開の重要な要素は、複数の時間ソースを使用する各クライアントです。複数のタイムソースがある場合、クライアントはさまざまなタイムソースを分析し、適切なタイムソースを選択し、不適切なタイムソースは無視します。単一のエニーキャストアドレスが使用されている場合、この分析は行われません。これは、複数の個別のエニーキャストプールを作成することで軽減できます。これにより、クライアントはエニーキャストプールの構成上の利点を活用しながら、複数の時間ソースを持つことができます。
If clients are connected to an NTP server via anycast, the client does not know which particular server they are connected to. As anycast servers enter and leave the network or the network topology changes, the server to which a particular client is connected may change. This may cause a small shift in time from the perspective of the client when the server to which it is connected changes. Extreme cases where the network topology changes rapidly could cause the server seen by a client to rapidly change as well, which can lead to larger time inaccuracies. It is RECOMMENDED that network operators only deploy anycast NTP in environments where operators know these small shifts can be tolerated by the applications running on the clients being synchronized in this manner.
クライアントがエニーキャストを介してNTPサーバーに接続されている場合、クライアントは、接続されている特定のサーバーを知りません。エニーキャストサーバーがネットワークに出入りするか、ネットワークトポロジが変化すると、特定のクライアントが接続されているサーバーが変化する可能性があります。これにより、クライアントが接続しているサーバーが変更されたときに、クライアントの観点から時間に少しずれが生じることがあります。ネットワークトポロジが急速に変化する極端なケースでは、クライアントから見たサーバーも急速に変化する可能性があり、時間の不正確さが大きくなる可能性があります。ネットワークオペレーターは、この方法で同期されているクライアントで実行されているアプリケーションがこれらの小さなシフトを許容できることをオペレーターが知っている環境でのみ、エニーキャストNTPを展開することをお勧めします。
Configuration of an anycast interface is independent of NTP. Clients will always connect to the closest server, even if that server is having NTP issues. It is RECOMMENDED that anycast NTP implementations have an independent method of monitoring the performance of NTP on a server. If the server is not performing to specification, it should remove itself from the anycast network. It is also RECOMMENDED that each anycast NTP server have an alternative method of access, such as an alternate unicast IP address, so its performance can be checked independently of the anycast routing scheme.
エニーキャストインターフェイスの設定は、NTPに依存しません。そのサーバーでNTPの問題が発生している場合でも、クライアントは常に最も近いサーバーに接続します。エニーキャストNTP実装には、サーバー上のNTPのパフォーマンスを監視する独立した方法があることをお勧めします。サーバーが仕様どおりに動作していない場合は、エニーキャストネットワークからサーバー自体を削除する必要があります。また、各エニーキャストNTPサーバーが代替ユニキャストIPアドレスなどの代替アクセス方法を備えていることをお勧めします。そのため、そのパフォーマンスはエニーキャストルーティング方式とは無関係に確認できます。
One useful application in large networks is to use a hybrid unicast/ anycast approach. Stratum 1 NTP servers can be deployed with unicast interfaces at several sites. Each site may have several Stratum 2 servers with two Ethernet interfaces or a single interface that can support multiple addresses. One interface has a unique unicast IP address. The second has an anycast IP interface (with a shared IP address per location). The unicast interfaces can be used to obtain time from the Stratum 1 servers globally (and perhaps peer with the other Stratum 2 servers at their site). Clients at each site can be configured to use the shared anycast address for their site, simplifying their configuration. Keeping the anycast routing restricted on a per-site basis will minimize the disruption at the client if its closest anycast server changes. Each Stratum 2 server can be uniquely identified on their unicast interface to make monitoring easier.
大規模ネットワークでの1つの有用なアプリケーションは、ハイブリッドユニキャスト/エニーキャストアプローチを使用することです。 Stratum 1 NTPサーバーは、複数のサイトにユニキャストインターフェイスを使用して展開できます。各サイトには、2つのイーサネットインターフェイスまたは複数のアドレスをサポートできる単一のインターフェイスを備えた複数のStratum 2サーバーがある場合があります。 1つのインターフェイスには、一意のユニキャストIPアドレスがあります。 2番目には、エニーキャストIPインターフェースがあります（ロケーションごとに共有IPアドレスを使用）。ユニキャストインターフェイスを使用して、Stratum 1サーバーからグローバルに時間を取得できます（おそらく、サイトにある他のStratum 2サーバーとピアリングします）。各サイトのクライアントは、サイトの共有エニーキャストアドレスを使用するように構成でき、構成が簡素化されます。サイトごとに制限されたエニーキャストルーティングを維持すると、最も近いエニーキャストサーバーが変更された場合のクライアントでの中断を最小限に抑えることができます。各Stratum 2サーバーは、ユニキャストインターフェイスで一意に識別できるため、監視が容易になります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Time is a fundamental component of security on the Internet. The absence of a reliable source of current time subverts many common web authentication schemes, e.g., by allowing the use of expired credentials or allowing the replay of messages only intended to be processed once.
時間はインターネットのセキュリティの基本的な要素です。現在時刻の信頼できるソースがないと、たとえば、有効期限が切れた資格情報の使用を許可したり、1度だけ処理することを目的としたメッセージの再生を許可したりするなど、多くの一般的なWeb認証スキームを覆します。
Much of this document directly addresses how to secure NTP servers. In particular, see Section 2, Section 4, and Section 5.
このドキュメントの多くは、NTPサーバーを保護する方法を直接扱っています。特に、セクション2、セクション4、およびセクション5を参照してください。
There are several general threats to time-synchronization protocols, which are discussed in [RFC7384].
[RFC7384]で説明されている、時刻同期プロトコルに対するいくつかの一般的な脅威があります。
[NTSFORNTP] specifies the Network Time Security (NTS) mechanism and applies it to NTP. Readers are encouraged to check the status of the document and make use of the methods it describes.
[NTSFORNTP]は、ネットワークタイムセキュリティ（NTS）メカニズムを指定し、それをNTPに適用します。読者は、ドキュメントのステータスを確認し、説明されている方法を利用することをお勧めします。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, DOI 10.17487/RFC4085, June 2005, <https://www.rfc-editor.org/info/rfc4085>.
[RFC4085]プロンカ、D。、「有害であると見なされるグローバルにルーティング可能なインターネットアドレスの埋め込み」、BCP 105、RFC 4085、DOI 10.17487 / RFC4085、2005年6月、<https://www.rfc-editor.org/info/rfc4085> 。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<https://www.rfc-editor.org/info/rfc4786> 。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <https://www.rfc-editor.org/info/rfc5905>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[AUTOKEY] Roettger, S., "Autokey-Protocol Analysis", August 2011, <https://lists.ntp.org/pipermail/ ntpwg/2011-August/001714.html>.
[AUTOKEY] Roettger、S。、「Autokey-Protocol Analysis」、2011年8月、<https://lists.ntp.org/pipermail/ ntpwg / 2011-August / 001714.html>。
[BCP38WIKI] "BCP38.info Wiki", October 2016, <bcp38.info">http://www.bcp38.info>.
[BCP38WIKI]「BCP38.info Wiki」、2016年10月、<bcp38.info "> http://www.bcp38.info>。
[CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's Authenticated Broadcast Mode", SIGCOMM Computer Communications Review (CCR) Volume 46, Issue 2, DOI 10.1145/2935634.2935637, April 2016.
[CCR16] Malhotra、A。およびS. Goldberg、「攻撃NTPの認証済みブロードキャストモード」、SIGCOMM Computer Communications Review（CCR）Volume 46、Issue 2、DOI 10.1145 / 2935634.2935637、2016年4月。
[CONFIGNTP] Network Time Foundation, "Configuring NTP", November 2018, <https://support.ntp.org/bin/view/Support/ConfiguringNTP>.
[CONFIGNTP] Network Time Foundation、「Configuring NTP」、2018年11月、<https://support.ntp.org/bin/view/Support/ConfiguringNTP>。
[CTRLMSG] Haberman, B., Ed., "Control Messages Protocol for Use with Network Time Protocol Version 4", Work in Progress, draft-ietf-ntp-mode-6-cmds-06, September 2018.
[CTRLMSG] Haberman、B。、編、「ネットワークタイムプロトコルバージョン4で使用するための制御メッセージプロトコル」、作業中、draft-ietf-ntp-mode-6-cmds-06、2018年9月。
[CVE-2015-8138] Van Gundy, M. and J. Gardner, "Network Time Protocol Origin Timestamp Check Impersonation Vulnerability", January 2016, <https://www.talosintel.com/reports/TALOS-2016-0077>.
[CVE-2015-8138] Van Gundy、M。およびJ. Gardner、「Network Time Protocol Origin Timestamp Check Impersonation Vulnerability」、2016年1月、<https://www.talosintel.com/reports/TALOS-2016-0077> 。
[CVE-2015-8139] Van Gundy, M., "Network Time Protocol ntpq and ntpdc Origin Timestamp Disclosure Vulnerability", January 2016, <https://www.talosintel.com/reports/TALOS-2016-0078>.
[CVE-2015-8139] Van Gundy、M。、「Network Time Protocol ntpq and ntpdc Origin Timestamp Disclosure Vulnerability」、2016年1月、<https://www.talosintel.com/reports/TALOS-2016-0078>。
[CVE-2016-1548] Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode to Interleaved", April 2016, <https://blog.talosintel.com/2016/04/ vulnerability-spotlight-further-ntpd_27.html>.
[CVE-2016-1548] Gardner、J。およびM. Lichvar、「Xleave Pivot：NTP Basic Mode to Interleaved」、2016年4月、<https://blog.talosintel.com/2016/04/脆弱性-スポットライト-遠方-ntpd_27.html>。
[DATAMIN] Franke, D. and A. Malhotra, "NTP Client Data Minimization", Work in Progress, draft-ietf-ntp-data-minimization-04, March 2019.
[DATAMIN] Franke、D。およびA. Malhotra、「NTP Client Data Minimization」、Work in Progress、draft-ietf-ntp-data-minimization-04、2019年3月。
[DDOS] Prince, M., "Technical Details Behind a 400Gbps NTP Amplification DDoS Attack", February 2014, <https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack>.
[DDOS] Prince、M。、「400Gbps NTP増幅DDoS攻撃の背後にある技術的な詳細」、2014年2月、<https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-攻撃>。
[IERS] IERS, "IERS Bulletins", <https://www.iers.org/IERS/EN/Publications/Bulletins/ bulletins.html>.
[IRISH] IRISH、「IRISH Bulletins」、<https://www.iers.org/IERS/EN/Publications/Bulletins/ bulletins.html>。
[IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C., Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla: The Rise and Decline of NTP DDoS Attacks", Proceedings of the 2014 Internet Measurement Conference, DOI 10.1145/2663716.2663717, November 2014.
[IMC14] Czyz、J.、Kallitsis、M.、Gharaibeh、M.、Papadopoulos、C.、Bailey、M。、およびM. Karir、「800ポンドのゴリラを飼いならす：NTP DDoS攻撃の増加と減少」、 2014年インターネット測定会議の議事録、DOI 10.1145 / 2663716.2663717、2014年11月。
[LEAPSEC] Burnicki, M., "Leap Second Smearing", <http://bk1.ntp.org/ ntp-stable/README.leapsmear?PAGE=anno>.
[LEAPSEC] Burnicki、M。、「Leap Second Smearing」、<http://bk1.ntp.org/ ntp-stable / README.leapsmear？PAGE = anno>。
[MILLS2006] Mills, D., "Computer network time synchronization: the Network Time Protocol", CRC Press, 2006.
[MILLS2006]ミルズD.、「コンピュータネットワークの時刻同期：ネットワークタイムプロトコル」、CRC Press、2006年。
[MISUSE] Wikipedia, "NTP Server Misuse and Abuse", May 2019, <https://en.wikipedia.org/w/index.php? title=NTP_server_misuse_and_abuse&oldid=899024751>.
[誤用] Wikipedia、「NTP Server Misuse and Abuse」、2019年5月、<https://en.wikipedia.org/w/index.php？ title = NTP_server_misuse_and_abuse＆oldid = 899024751>。
[NDSS14] Rossow, C., "Amplification Hell: Revisiting Network Protocols for DDoS Abuse", Network and Distributed System Security (NDSS) Symposium 2014, DOI 10.14722/ndss.2014.23233, February 2014, <https://www.ndss-symposium.org/ndss2014/programme/ amplification-hell-revisiting-network-protocols-ddos-abuse/>.
[NDSS14] Rossow、C。、「Amplification Hell：Revisiting Network Protocols for DDoS Abuse」、ネットワークおよび分散システムセキュリティ（NDSS）シンポジウム2014、DOI 10.14722 / ndss.2014.23233、2014年2月、<https：//www.ndss- symposium.org/ndss2014/programme/増幅-地獄-revisiting-network-protocols-ddos-abuse />。
[NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, "Attacking the Network Time Protocol", Network and Distributed System Security (NDSS) Symposium 2016, DOI 10.14722/ndss.2016.23090, February 2016, <https://eprint.iacr.org/2015/1020.pdf>.
[NDSS16] Malhotra、A.、Cohen、I.、Brackke、E。、およびS. Goldberg、「Attacking the Network Time Protocol」、Network and Distributed System Security（NDSS）Symposium 2016、DOI 10.14722 / ndss.2016.23090、February 2016、<https://eprint.iacr.org/2015/1020.pdf>。
[NTPDOWN] Network Time Foundation, "NTP Software Downloads", <http://www.ntp.org/downloads.html>.
[NTPDOWN] Network Time Foundation、「NTP Software Downloads」、<http://www.ntp.org/downloads.html>。
[NTSFORNTP] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", Work in Progress, draft-ietf-ntp-using-nts-for-ntp-20, July 2019.
[NTSFORNTP] Franke、D.、Sibold、D.、Teichel、K.、Dansarie、M。、およびR. Sundblad、「Network Time Security for the Network Time Protocol」、Work in Progress、draft-ietf-ntp-using -nts-for-ntp-20、2019年7月。
[POOLUSE] NTP Pool Project, "Use the Pool", <https://www.pool.ntp.org/en/use.html>.
[POOLUSE] NTPプールプロジェクト、「Use the Pool」、<https://www.pool.ntp.org/en/use.html>。
[POOLVENDOR] NTP Pool Project, "The NTP Pool for Vendors", <https://www.pool.ntp.org/en/vendors.html>.
[POOLVENDOR] NTPプールプロジェクト、「ベンダー向けNTPプール」、<https://www.pool.ntp.org/en/vendors.html>。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, DOI 10.17487/RFC1305, March 1992, <https://www.rfc-editor.org/info/rfc1305>.
[RFC1305] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、DOI 10.17487 / RFC1305、1992年3月、<https://www.rfc-editor.org/info/rfc1305 >。
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, DOI 10.17487/RFC5906, June 2010, <https://www.rfc-editor.org/info/rfc5906>.
[RFC5906]ハーバーマン、B。、エド。およびD. Mills、「Network Time Protocol Version 4：Autokey Specification」、RFC 5906、DOI 10.17487 / RFC5906、2010年6月、<https://www.rfc-editor.org/info/rfc5906>。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6151]ターナーS.およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<https：//www.rfc- editor.org/info/rfc6151>。
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.
[RFC7094] McPherson、D.、Oran、D.、Thaler、D。、およびE. Osterweil、「IP Anycastのアーキテクチャに関する考慮事項」、RFC 7094、DOI 10.17487 / RFC7094、2014年1月、<https：//www.rfc -editor.org/info/rfc7094>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384]ミズラヒ、T。、「パケット交換ネットワークにおけるタイムプロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https://www.rfc-editor.org/info/rfc7384>。
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code for the Network Time Protocol", RFC 8573, DOI 10.17487/RFC8573, June 2019, <https://www.rfc-editor.org/info/rfc8573>.
[RFC8573] Malhotra、A。およびS. Goldberg、「Network Time Protocolのメッセージ認証コード」、RFC 8573、DOI 10.17487 / RFC8573、2019年6月、<https://www.rfc-editor.org/info/rfc8573 >。
[SOLAR] Wikipedia, "Solar Time", May 2019, <https://en.wikipedia.org/w/index.php? title=Solar_time&oldid=896601472#Mean_solar_time>.
[SOLAR] Wikipedia、「Solar Time」、2019年5月、<https://en.wikipedia.org/w/index.php？ title = Solar_time＆oldid = 896601472＃Mean_solar_time>。
Appendix A. Best Practices Specific to the Network Time Foundation Implementation
付録A. Network Time Foundation実装に固有のベストプラクティス
The Network Time Foundation (NTF) provides a widely used implementation of NTP, known as ntpd [NTPDOWN]. It is an evolution of the first NTP implementations developed by David Mills at the University of Delaware. This appendix contains additional recommendations specific to this implementation that are valid at the time of this writing.
Network Time Foundation（NTF）は、ntpd [NTPDOWN]として知られる、広く使用されているNTPの実装を提供します。これは、デラウェア大学のDavid Millsによって開発された最初のNTP実装の進化形です。この付録には、この執筆時点で有効な、この実装に固有の追加の推奨事項が含まれています。
In addition to the recommendation given in Section 3.2, the ntpd implementation provides the 'pool' directive. Starting with ntp-4.2.6, using this directive in the ntp.conf file will spin up enough associations to provide robust time service and will disconnect poor servers and add in new servers as needed. The 'minclock' and 'maxclock' options of the 'tos' command may be used to override the default values of how many servers are discovered through the 'pool' directive.
セクション3.2で与えられた推奨に加えて、ntpd実装は 'pool'ディレクティブを提供します。 ntp-4.2.6から、ntp.confファイルでこのディレクティブを使用すると、十分な関連付けが確立され、堅牢なタイムサービスが提供され、貧弱なサーバーが切断され、必要に応じて新しいサーバーが追加されます。 「tos」コマンドの「minclock」および「maxclock」オプションを使用して、「pool」ディレクティブを通じて検出されるサーバー数のデフォルト値を上書きできます。
In addition to NTP control messages, the ntpd implementation also offers the Mode 7 commands for monitoring and configuration.
NTP制御メッセージに加えて、ntpd実装は、監視と構成のためのモード7コマンドも提供します。
If Mode 7 has been explicitly enabled to be used for more than basic monitoring, it should be limited to authenticated sessions that provide a 'requestkey'.
モード7が基本的な監視以外にも使用できるように明示的に有効になっている場合は、「リクエストキー」を提供する認証済みセッションに限定する必要があります。
As mentioned above, there are two general ways to use Mode 6 and Mode 7 requests. One way is to query ntpd for information, and this mode can be disabled with:
上記のように、モード6とモード7の要求を使用するには、2つの一般的な方法があります。 1つの方法は、ntpdに情報を問い合わせることです。このモードは、次のコマンドで無効にできます。
restrict ... noquery
制限... noquery
The second way to use Mode 6 and Mode 7 requests is to modify ntpd's behavior. Modification of ntpd's configuration requires an authenticated session by default. If no authentication keys have been specified, no modifications can be made. For additional protection, the ability to perform these modifications can be controlled with:
モード6およびモード7要求を使用する2番目の方法は、ntpdの動作を変更することです。 ntpdの設定を変更するには、デフォルトで認証されたセッションが必要です。認証キーが指定されていない場合、変更はできません。追加の保護のために、これらの変更を実行する機能は次のように制御できます。
restrict ... nomodify Users can prevent their NTP servers from considering query/ configuration traffic by default by adding the following to their ntp.conf file:
restrict ... nomodifyユーザーは、次の行をntp.confファイルに追加することにより、デフォルトでNTPサーバーがクエリ/構成トラフィックを考慮しないようにすることができます。
restrict default -4 nomodify notrap nopeer noquery
デフォルトを制限-4 nomodify notrap nopeer noquery
restrict default -6 nomodify notrap nopeer noquery
デフォルトを制限-6 nomodify notrap nopeer noquery
restrict source nomodify notrap noquery
ソースnomodify notrap noqueryを制限する
The ntpd implementation allows remote monitoring. Access to this service is generally controlled by the "noquery" directive in NTP's configuration file (ntp.conf) via a "restrict" statement. The syntax reads:
ntpdの実装により、リモート監視が可能になります。このサービスへのアクセスは、通常、「restrict」ステートメントを介して、NTPの構成ファイル（ntp.conf）の「noquery」ディレクティブによって制御されます。構文は次のとおりです。
restrict address mask address_mask noquery
アドレスマスクを制限します。
If a system is using broadcast mode and is running ntp-4.2.8p6 or later, use the fourth field of the ntp.keys file to specify the IPs of machines that are allowed to serve time to the group.
システムがブロードキャストモードを使用していて、ntp-4.2.8p6以降を実行している場合は、ntp.keysファイルの4番目のフィールドを使用して、グループに時間を提供できるマシンのIPを指定します。
The use of leap-second files requires ntpd 4.2.6 or later. After fetching the leap-second file onto the server, add this line to ntpd.conf to apply and use the file, substituting the proper path:
うるう秒ファイルを使用するには、ntpd 4.2.6以降が必要です。うるう秒ファイルをサーバーにフェッチした後、この行をntpd.confに追加してファイルを適用および使用し、適切なパスに置き換えます。
leapfile "/path/to/leap-file"
There may be a need to restart ntpd to apply this change.
この変更を適用するには、ntpdを再起動する必要がある場合があります。
ntpd servers with a manually configured leap-second file will ignore a leap-second information broadcast from upstream NTP servers until the leap-second file expires. If no valid leap-second file is available, then a leap-second notification from an attached reference clock is always accepted by ntpd.
手動でうるう秒ファイルを構成したntpdサーバーは、うるう秒ファイルが期限切れになるまで、アップストリームNTPサーバーからブロードキャストされるうるう秒情報を無視します。有効なうるう秒ファイルが使用できない場合、接続されている基準クロックからのうるう秒通知は、常にntpdによって受け入れられます。
If no valid leap-second file is available, a leap-second notification may be accepted from upstream NTP servers. As of ntp-4.2.6, a majority of servers must provide the notification before it is accepted. Before 4.2.6, a leap-second notification would be accepted if a single upstream server of a group of configured servers provided a leap-second notification. This would lead to misbehavior if single NTP servers sent an invalid leap second warning, e.g., due to a faulty GPS receiver in one server, but this behavior was once chosen because in the "early days", there was a greater chance that leap- second information would be available from a very limited number of sources.
有効なうるう秒ファイルが使用できない場合、うるう秒通知が上流のNTPサーバーから受け入れられることがあります。 ntp-4.2.6以降、大多数のサーバーは通知を受け入れる前に通知を提供する必要があります。 4.2.6より前は、設定されたサーバーのグループの単一の上流サーバーがうるう秒通知を提供した場合、うるう秒通知が受け入れられていました。たとえば、1つのサーバーのGPSレシーバーの障害が原因で、単一のNTPサーバーが無効なうるう秒の警告を送信した場合、これは誤動作につながりますが、この動作はかつて選択されました。 2番目の情報は、非常に限られた数のソースから入手できます。
Leap smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47 in response to client requests. Support for leap smearing is not configured by default and must be added at compile time. In addition, no leap smearing will occur unless a leap smear interval is specified in ntpd.conf. For more information, refer to [LEAPSEC].
リープスミアは、クライアントの要求に応じてntpdバージョン4.2.8.p3および4.3.47で導入されました。うるうにじみのサポートはデフォルトでは設定されておらず、コンパイル時に追加する必要があります。さらに、うるうスミア間隔がntpd.confで指定されていない限り、うるうスミアは発生しません。詳細については、[LEAPSEC]を参照してください。
See [CONFIGNTP] for additional information on configuring ntpd.
ntpdの構成の詳細については、[CONFIGNTP]を参照してください。
Each communication partner must add the key information to their key file in the form:
各通信パートナーは、次の形式でキーファイルにキー情報を追加する必要があります。
keyid type key
keyidタイプのキー
where "keyid" is a number between 1 and 65534, inclusive; "type" is an ASCII character that defines the key format; and "key" is the key itself.
「keyid」は1から65534までの数値です。 「タイプ」は、キー形式を定義するASCII文字です。 「キー」はキーそのものです。
An ntpd client establishes a protected association by appending the option "key keyid" to the server statement in ntp.conf,
ntpdクライアントは、ntp.confのサーバーステートメントにオプション「key keyid」を追加することにより、保護された関連付けを確立します。
server address key keyid
サーバーアドレスキーkeyid
substituting the server address in the "address" field and the numerical keyid to use with that server in the "keyid" field.
「アドレス」フィールドにサーバーアドレスを代入し、「キーID」フィールドにそのサーバーで使用する数値のキーIDを代入します。
A key is deemed trusted when its keyid is added to the list of trusted keys by the "trustedkey" statement in ntp.conf.
ntp.confの「trustedkey」ステートメントによってキーIDが信頼できるキーのリストに追加されると、キーは信頼できると見なされます。
trustedkey keyid_1 keyid_2 ... keyid_n
trustedkey keyid_1 keyid_2 ... keyid_n
Starting with ntp-4.2.8p7, the ntp.keys file accepts an optional fourth column, a comma-separated list of IPs that are allowed to serve time. Use this feature. Note, however, that an adversarial client that knows the symmetric broadcast key could still easily spoof its source IP to an IP that is allowed to serve time. This is easy to do because the origin timestamp on broadcast mode packets is not validated by the client. By contrast, client/server and symmetric modes do require origin timestamp validation, making it more difficult to spoof packets [CCR16].
ntp-4.2.8p7以降、ntp.keysファイルは、オプションで4番目の列、時間の提供を許可されているIPのコンマ区切りリストを受け入れます。この機能を使用します。ただし、対称ブロードキャストキーを知っている敵対的なクライアントは、ソースIPを、時間を提供できるIPに簡単にスプーフィングできることに注意してください。ブロードキャストモードパケットの元のタイムスタンプはクライアントによって検証されないため、これは簡単に実行できます。対照的に、クライアント/サーバーモードと対称モードでは、元のタイムスタンプの検証が必要なので、パケットのなりすましが困難になります[CCR16]。
Acknowledgments
謝辞
The authors wish to acknowledge the contributions of Sue Graves, Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, Robert Nagy, and Brian Haberman.
著者は、スーグレイブス、サミュエルウェイラー、リサペルデュー、カレンオドノヒュー、デビッドマローン、シャロンゴールドバーグ、マーティンバーニッキ、ミロスラフリヒバール、ダニエルフォックスフランケ、ロバートナジ、ブライアンハーバーマンの貢献に感謝します。
Authors' Addresses
著者のアドレス
Denis Reilly (editor) Orolia USA 1565 Jefferson Road, Suite 460 Rochester, NY 14623 United States of America
Denis Reilly（editor）Orolia USA 1565 Jefferson Road、Suite 460 Rochester、NY 14623アメリカ合衆国
Email: denis.reilly@orolia.com
Harlan Stenn Network Time Foundation P.O. Box 918 Talent, OR 97540 United States of America
Harlan Stenn Network Time Foundation P.O. Box 918 Talent、OR 97540アメリカ合衆国
Email: stenn@nwtime.org
Dieter Sibold Physikalisch-Technische Bundesanstalt Bundesallee 100 Braunschweig D-38116 Germany
Dieter Sibold Physikalisch-Technische Bundesanstalt Bundesallee 100ブラウンシュヴァイクD-38116ドイツ
Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420
Email: dieter.sibold@ptb.de