[要約] RFC 9109は、ネットワークタイムプロトコルバージョン4 (NTPv4) のポートランダマイゼーションに関する文書です。この文書の目的は、NTPクライアントとサーバー間の通信におけるセキュリティを強化するため、ソースポートのランダマイゼーションを導入することです。これは、特に分散サービス拒否（DDoS）攻撃の緩和や、マン・イン・ザ・ミドル攻撃のリスクを減少させる場面で利用されます。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 9109 G. Gont
Updates: 5905 SI6 Networks
Category: Standards Track M. Lichvar
ISSN: 2070-1721 Red Hat
August 2021
Network Time Protocol Version 4: Port Randomization
ネットワークタイムプロトコルバージョン4：ポートランダム化
Abstract
概要
The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.
ネットワークタイムプロトコル（NTP）はいくつかのモードで動作できます。これらのモードのいくつかは、迷惑なパケットの受信に基づいており、したがってローカルポートとしてよく知られているポートを使用する必要があります。しかしながら、周知のポートの使用が必要とされないNTPモードの場合、そのような周知のポートを使用することは不必要に攻撃者がブラインド/オフパス攻撃を実行する能力を容易にする。この文書では、RFC 5905を正式に更新し、NTP周知のポートの使用が不要なモードのトランスポートプロトコルの一時ポートランダム化の使用を推奨します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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 Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、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/rfc9109.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9109で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Considerations about Port Randomization in NTP
3.1. Mitigation against Off-Path Attacks
3.2. Effects on Path Selection
3.3. Filtering of NTP Traffic
3.4. Effect on NAPT Devices
4. Update to RFC 5905
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
The Network Time Protocol (NTP) is one of the oldest Internet protocols and is currently specified in [RFC5905]. Since its original implementation, standardization, and deployment, a number of vulnerabilities have been found both in the NTP specification and in some of its implementations [NTP-VULN]. Some of these vulnerabilities allow for blind/off-path attacks, where an attacker can send forged packets to one or both NTP peers to achieve Denial of Service (DoS), time shifts, or other undesirable outcomes. Many of these attacks require the attacker to guess or know at least a target NTP association, typically identified by the tuple {srcaddr, srcport, dstaddr, dstport, keyid} (see Section 9.1 of [RFC5905]). Some of these parameters may be known or easily guessed.
ネットワークタイムプロトコル（NTP）は最も古いインターネットプロトコルの1つであり、現在[RFC5905]で指定されています。元の実装、標準化、および展開は、NTP仕様の両方とその実装の一部の両方で数多くの脆弱性が見つかりました[NTP-vuln]。これらの脆弱性のいくつかは、攻撃者が譲渡業者が片方または両方のNTPピアにサービスを送ることができ、サービス拒否（DOS）、タイムシフト、またはその他の望ましくない結果を得ることができる。これらの攻撃の多くは、攻撃者に少なくともターゲットNTPアソシエーションを推測または知っており、通常はTuple {srcaddr、srcport、dstaddr、dstport、keyid}によって識別されます（[RFC5905]のセクション9.1を参照）。これらのパラメータのいくつかは既知または容易に推測され得る。
NTP can operate in several modes. Some of these modes rely on the ability of nodes to receive unsolicited packets and therefore require the use of the NTP well-known port (123). However, for modes where the use of a well-known port is not required, employing the NTP well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks (since knowledge of the port numbers is typically required for such attacks). A recent study [NIST-NTP] that analyzes the port numbers employed by NTP clients suggests that numerous NTP clients employ the NTP well-known port as their local port, or select predictable ephemeral port numbers, thus unnecessarily facilitating the ability of attackers to perform blind/ off-path attacks against NTP.
NTPはいくつかのモードで動作することができます。これらのモードのいくつかは、ノードが迷惑なパケットを受信する能力に依存しており、したがってNTP周知のポート（123）の使用を必要とする。しかしながら、よく知られているポートの使用が不要であるモードでは、NTP周知のポートを使用することは不必要に攻撃者がブラインド/オフパス攻撃を実行する能力を促進する（ポート番号の知識が通常必要とされるので）。攻撃）最近の研究[NTP-NTP] NTPクライアントが使用しているポート番号を分析することは、数多くのNTPクライアントがローカルポートとしてNTP周知のポートを使用するか、または予測可能なエフェラルポート番号を選択すること、したがって攻撃者の実行能力を不必要に容易にすることを示唆しています。NTPに対するブラインド/オフパス攻撃。
BCP 156 [RFC6056] already recommends the randomization of transport-protocol ephemeral ports. This document aligns NTP with the recommendation in BCP 156 [RFC6056] by formally updating [RFC5905] such that port randomization is employed for those NTP modes for which the use of the NTP well-known port is not needed.
BCP 156 [RFC6056]はすでにトランスポートプロトコルエフェラルポートのランダム化をお勧めします。この文書は、NTP周知のポートの使用が不要なNTPモードにポートのランダム化が採用されるように、[RFC5905]を正式に更新することで、NTPをBCP 156 [RFC6056]で推奨します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following subsections analyze a number of considerations about transport-protocol ephemeral port randomization when applied to NTP.
次のサブセクションでは、NTPに適用されたときのトランスポートプロトコルの一時ポートのランダム化に関するいくつかの考慮事項を分析します。
There has been a fair share of work in the area of blind/off-path attacks against transport protocols and upper-layer protocols, such as [RFC4953] and [RFC5927]. Whether the target of the attack is a transport-protocol instance (e.g., TCP connection) or an upper-layer protocol instance (e.g., an application-protocol instance), the attacker is required to know or guess the five-tuple {Protocol, IP Source Address, IP Destination Address, Source Port, Destination Port} that identifies the target transport-protocol instance or the transport-protocol instance employed by the target upper-layer protocol instance. Therefore, increasing the difficulty of guessing this five-tuple helps mitigate blind/off-path attacks.
[RFC4953]や[RFC5927]など、トランスポートプロトコルと上位レイヤープロトコルに対するブラインド/オフパス攻撃の分野での公正な割合がありました。攻撃のターゲットがトランスポートプロトコルインスタンス（たとえば、TCP接続）か上位レイヤプロトコルインスタンス（例えば、アプリケーションプロトコルインスタンス）であるかどうか、攻撃者は5タプル{プロトコルを知るか推測する必要があります。IP送信元アドレス、IP宛先アドレス、送信元ポート、ターゲットトランスポートプロトコルインスタンスまたはターゲット上位層プロトコルインスタンスによって採用されているトランスポートプロトコルインスタンスを識別します。したがって、この5つのタプルを推測することの難しさを高めることは、盲目/オフパス攻撃を軽減するのに役立ちます。
As a result of these considerations, transport-protocol ephemeral port randomization is a best current practice (BCP 156) that helps mitigate off-path attacks at the transport layer. This document aligns the NTP specification [RFC5905] with the existing best current practice on transport-protocol ephemeral port selection, irrespective of other techniques that may (and should) be implemented for mitigating off-path attacks.
これらの考慮の結果として、トランスポートプロトコルの一時的なポートのランダム化は、トランスポート層でのオフパス攻撃を軽減するのに役立つ最良の現在の慣例です。この文書は、OFF-PATH攻撃を軽減するために実行される可能性がある他の技術に関係なく、トランスポートプロトコルの一時ポートの選択に関係なく、NTP仕様[RFC5905]をトランスポートプロトコルのエフェラルポート選択に揃えます。
We note that transport-protocol ephemeral port randomization is a transport-layer mitigation against blind/off-path attacks and does not preclude (nor is it precluded by) other possible mitigations for off-path attacks that might be implemented at other layers (e.g., [NTP-DATA-MINIMIZATION]). For instance, some of the aforementioned mitigations may be ineffective against some off-path attacks [NTP-FRAG] or may benefit from the additional entropy provided by port randomization [NTP-security].
転送プロトコルの一時的なポートのランダム化は、ブラインド/オフパスの攻撃に対するトランスポート層の軽減であり、除外されない（排除されていません）他の層で実装される可能性があるオフパス攻撃のための他の可能な緩和、[NTPデータ最小化]）。例えば、前述の緩和のいくつかは、いくつかのオフパス攻撃に対して無効であり得る（NTP - Frag]またはポートランダム化によって提供される追加のエントロピー[NTPセキュリティ]から利益を得ることができる。
Intermediate systems implementing the Equal-Cost Multipath (ECMP) algorithm may select the outgoing link by computing a hash over a number of values, including the transport-protocol source port. Thus, as discussed in [NTP-CHLNG], the selected client port may have an influence on the measured offset and delay.
等価マルチパス（ECMP）アルゴリズムを実装する中間システムは、トランスポートプロトコルソースポートを含む、いくつかの値にわたってハッシュを計算することによって発信リンクを選択することができる。したがって、[NTP-CHLNG]で説明したように、選択されたクライアントポートは、測定されたオフセットおよび遅延に影響を与える可能性があります。
If the source port is changed with each request, packets in different exchanges will be more likely to take different paths, which could cause the measurements to be less stable and have a negative impact on the stability of the clock.
ソースポートが各要求で変更された場合、異なる交換内のパケットは異なるパスを撮影する可能性が高くなり、測定値が安定しなくなり、クロックの安定性に悪影響を及ぼします。
Network paths to/from a given server are less likely to change between requests if port randomization is applied on a per-association basis. This approach minimizes the impact on the stability of NTP measurements, but it may cause different clients in the same network synchronized to the same NTP server to have a significant stable offset between their clocks. This is due to their NTP exchanges consistently taking different paths with different asymmetry in the network delay.
ポートのランダム化が関連付けごとに適用されている場合、指定されたサーバーへの/からのネットワークパスは、要求間で変更される可能性が低いです。このアプローチは、NTP測定の安定性への影響を最小限に抑えるが、同じネットワーク内の同じネットワーク内のクライアントが同じNTPサーバと同期してクロック間で有意に安定したオフセットを生じさせる可能性があります。これは、ネットワーク遅延で異なる非対称性を持つ異なるパスを一貫してNTP交換しているためです。
Section 4 recommends that NTP implementations randomize the ephemeral port number of client/server associations. The choice of whether to randomize the port number on a per-association or a per-request basis is left to the implementation.
NTP実装が、クライアント/サーバの関連付けの一時ポート番号をランダム化することをお勧めします。関連付けごとにポート番号をランダム化するか要求ごとにランダム化するかどうかの選択は実装に残されています。
In a number of scenarios (such as when mitigating DDoS attacks), a network operator may want to differentiate between NTP requests sent by clients and NTP responses sent by NTP servers. If an implementation employs the NTP well-known port for the client port, requests/responses cannot be readily differentiated by inspecting the source and destination port numbers. Implementation of port randomization for nonsymmetrical modes allows for simple differentiation of NTP requests and responses and for the enforcement of security policies that may be valuable for the mitigation of DDoS attacks, when all NTP clients in a given network employ port randomization.
（DDOS攻撃を軽減するときなど）、ネットワークオペレータは、NTPサーバによって送信されたNTP応答とNTP応答を区別したいと思うかもしれません。実装がクライアントポートにNTP周知のポートを使用している場合、要求/応答は、送信元のポート番号と宛先のポート番号を調べることで容易に区別できません。非対称モードのポートランダム化の実装は、NTP要求と応答の簡単な区別、および特定のネットワーク内のすべてのNTPクライアントがポートのランダム化を採用している場合、DDOS攻撃の軽減に貴重なセキュリティポリシーの強制を可能にします。
Some NAPT devices will reportedly not translate the source port of a packet when a system port number (i.e., a port number in the range 0-1023) [RFC6335] is employed. In networks where such NAPT devices are employed, use of the NTP well-known port for the client port may limit the number of hosts that may successfully employ NTP client implementations at any given time.
一部のNAPTデバイスは、システムポート番号（すなわち、0~1023の範囲のポート番号）[RFC6335]が採用されている場合に、パケットの送信元ポートを通知しないと報告される。そのようなNAPTデバイスが使用されるネットワークでは、クライアントポートのNTP周知のポートを使用すると、任意の時間にNTPクライアント実装を正常に使用することができるホストの数が制限される可能性があります。
| NOTES:
|
| NAPT devices are defined in Section 4.1.2 of [RFC2663].
|
| The reported behavior is similar to the special treatment of
| UDP port 500, which has been documented in Section 2.3 of
| [RFC3715].
In the case of NAPT devices that will translate the source port even when a system port is employed, packets reaching the external realm of the NAPT will not employ the NTP well-known port as the source port, as a result of the port translation function being performed by the NAPT device.
システムポートを採用してもソースポートを翻訳するNAPTデバイスの場合、Port Translation Functionの結果として、NAPTの外部レルムに到達するパケットは、NTP周知のポートをソースポートとして使用しません。NAPT装置によって実行される。
The following text from Section 9.1 (Peer Process Variables) of [RFC5905]:
[RFC5905]のセクション9.1（Peer Process Variables）からの次のテキスト：
| dstport: UDP port number of the client, ordinarily the NTP port
| number PORT (123) assigned by the IANA. This becomes the
| source port number in packets sent from this association.
is replaced with:
に置き換えられます。
| dstport: UDP port number of the client. In the case of broadcast
| server mode (5) and symmetric modes (1 and 2), it SHOULD
| contain the NTP port number PORT (123) assigned by IANA. In
| the client mode (3), it SHOULD contain a randomized port
| number, as specified in [RFC6056]. The value in this variable
| becomes the source port number of packets sent from this
| association. The randomized port number SHOULD NOT be shared
| with other associations, to avoid revealing the randomized port
| to other associations.
|
| If a client implementation performs transport-protocol
| ephemeral port randomization on a per-request basis, it SHOULD
| close the corresponding socket/port after each request/response
| exchange. In order to prevent duplicate or delayed server
| packets from eliciting ICMP port unreachable error messages
| [RFC0792] [RFC4443] at the client, the client MAY wait for more
| responses from the server for a specific period of time (e.g.,
| 3 seconds) before closing the UDP socket/port.
|
|
| NOTES:
|
| Randomizing the ephemeral port number on a per-request basis
| will better mitigate blind/off-path attacks, particularly if
| the socket/port is closed after each request/response
| exchange, as recommended above. The choice of whether to
| randomize the ephemeral port number on a per-request or a
| per-association basis is left to the implementation, and it
| should consider the possible effects on path selection along
| with its possible impact on time measurement.
|
| On most current operating systems, which implement ephemeral
| port randomization [RFC6056], an NTP client may normally
| rely on the operating system to perform ephemeral port
| randomization. For example, NTP implementations using POSIX
| sockets may achieve ephemeral port randomization by _not_
| binding the socket with the bind() function or binding it to
| port 0, which has a special meaning of "any port". Using
| the connect() function for the socket will make the port
| inaccessible by other systems (that is, only packets from
| the specified remote socket will be received by the
| application).
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security implications of predictable numeric identifiers [PEARG-NUMERIC-IDS] (and of predictable transport-protocol port numbers [RFC6056] in particular) have been known for a long time now. However, the NTP specification has traditionally followed a pattern of employing common settings even when not strictly necessary, which at times has resulted in negative security and privacy implications (see, e.g., [NTP-DATA-MINIMIZATION]). The use of the NTP well-known port (123) for the srcport and dstport variables is not required for all operating modes. Such unnecessary usage comes at the expense of reducing the amount of work required for an attacker to successfully perform blind/off-path attacks against NTP. Therefore, this document formally updates [RFC5905], recommending the use of transport-protocol port randomization when use of the NTP well-known port is not required.
予測可能な数値識別子[PEERG-NUMERIC-IDS]（および特に予測可能なトランスポートプロトコルポート番号）のセキュリティへの影響は、長い間知られています。しかしながら、NTP仕様は伝統的には厳密に必要ではない場合でも共通の設定を採用したパターンを採用しており、それは時々否定的なセキュリティおよびプライバシーの意味をもたらした（例えば、[NTPデータ最小化]参照）。SRCPORT変数とDSTPORT変数に対するNTP周知のポート（123）を使用することは、すべての動作モードには必要ありません。このような不要な使用法は、攻撃者がNTPに対するブラインド/オフパス攻撃をうまく実行するのに必要な作業量を減らすことを犠牲にしています。したがって、この文書では、NTP周知のポートを使用する場合のトランスポートプロトコルポートのランダム化の使用を推奨する[RFC5905]が正式に更新されます。
This issue has been assigned CVE-2019-11331 [VULN-REPORT] in the U.S. National Vulnerability Database (NVD).
この問題には、米国国家脆弱性データベース（NVD）にCVE-2019-11331 [Vuln-Report]が割り当てられています。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <https://www.rfc-editor.org/info/rfc6056>.
[RFC6056] Larsen、M.およびF.は、「トランスポートプロトコルポートランダム化のための推奨事項」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<https：//www.rfc-editor.org/info/ RFC6056>。
[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>。
[NIST-NTP] Sherman, J. and J. Levine, "Usage Analysis of the NIST Internet Time Service", Journal of Research of the National Institute of Standards and Technology, Volume 121, DOI 10.6028/jres.121.003, March 2016, <https://tf.nist.gov/general/pdf/2818.pdf>.
[NIST-NTP] Sherman、J.およびJ. Levine、「NISTインターネットタイムサービスの使用状況分析」、国立標準技術研究所、巻121、DOI 10.6028 / JRES.121.003、2016年3月、<https://tf.nist.gov/general/pdf/2818.pdf>。
[NTP-CHLNG] Sommars, S., "Challenges in Time Transfer using the Network Time Protocol (NTP)", Proceedings of the 48th Annual Precise Time and Time Interval Systems and Applications Meeting, pp. 271-290, DOI 10.33012/2017.14978, January 2017, <http://leapsecond.com/ntp/ NTP_Paper_Sommars_PTTI2017.pdf>.
[NTP-CHLNG]ソマル、S。、「ネットワークタイムプロトコル（NTP）を使用した時間転送の課題、48回目の正確な時間と時間間隔システムとアプリケーション会議、PP。271-290、DOI 10.33012 / 2017.149782017年1月、<http://leapsecond.com/ntp/ ntp_paper_sommars_pttti2017.pdf>。
[NTP-DATA-MINIMIZATION] Franke, D. and A. Malhotra, "NTP Client Data Minimization", Work in Progress, Internet-Draft, draft-ietf-ntp-data-minimization-04, 25 March 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization-04>.
[NTPデータ最小化] Franke、D.およびA.Malhotra、「NTPクライアントデータ最小化」、進行中の作業、インターネットドラフト、Draft-IETF-NTP-Data-Minimization-04,25,2019、<HTTPS：//datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization-04>。
[NTP-FRAG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, "Attacking the Network Time Protocol", NDSS '16, DOI 10.14722/ndss.2016.23090, February 2016, <https://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf>.
[NTP-Frag] Malhotra、A.、Cohen、I.、Brakke、E.、およびS.goldberg、「ネットワークタイムプロトコルの攻撃」、NDSS '16、DOI 10.14722 / NDSS.2016.23090、2016.23090、2016.23090、<https：//www.cs.bu.edu/~goldbe/papers/ntpattack.pdf>。
[NTP-security] Malhotra, A., Van Gundy, M., Varia, M., Kennedy, H., Gardner, J., and S. Goldberg, "The Security of NTP's Datagram Protocol", Cryptology ePrint Archive Report 2016/1006, DOI 10.1007/978-3-319-70972-7_23, February 2017, <https://eprint.iacr.org/2016/1006.pdf>.
[NTP-Security] Malhotra、A.、Van Gundy、M.、Varia、M.、Kennedy、H.、Gardner、J.、およびS.goldberg、「NTPのデータグラムプロトコルのセキュリティ」、暗号化Eprint Archive Report 2016/ 1006、DOI 10.1007 / 978-3-319-70972-7_23、2017年2月、<https：//eprint.iacr.org/2016/1006.pdf>。
[NTP-VULN] "Network Time Foundation", <http://support.ntp.org/bin/view/Main/SecurityNotice>.
[NTP-vuln] "Network Time Foundation"、<http://support.ntp.org/bin/view/main/securityNotice>
[PEARG-NUMERIC-IDS] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-07, 2 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-07>.
[PEERG-NUMERIC-IDS] GONT、F.およびI.ARCE、「一時的な数値識別子の生成」、進行中の作業、インターネットドラフト、ドラフト-IRTF-Pearg-Numeric-IDS-Generation-07,2 2月2日2021、<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric -ids-generation-07>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] SRISERSH、P.およびM.OLSREGE、「IPネットワークアドレストランスレータ（NAT）用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<https：//www.rfc-editor.org/info/ RFC2663>。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, DOI 10.17487/RFC3715, March 2004, <https://www.rfc-editor.org/info/rfc3715>.
[RFC3715] Aboba、B.およびW.Dixon、「IPsec-Network Address翻訳（NAT）互換性要件」、RFC 3715、DOI 10.17487 / RFC3715、2004年3月、<https：//www.rfc-editor.org/info/ RFC3715>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.
[RFC4953] Touch、J.、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、DOI 10.17487 / RFC4953、2007年7月、<https：//www.rfc-editor.org/info/rfc4953>。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>.
[RFC5927] Gont、F.、「TCPに対するICMP攻撃」、RFC 5927、DOI 10.17487 / RFC5927、<https：//www.rfc-editor.org/info/rfc5927>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M.、Eggert、L.、Touch、J.、Westerlund、M.、S. Cheshire、「インターネット割り当て番号局（IANA）サービス名とトランスポートプロトコルポート番号レジストリの管理の手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https：//www.rfc-editor.org/info/rfc6335>。
[VULN-REPORT] The MITRE Corporation, "CVE-2019-1133", National Vulnerability Database, August 2020, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11331>.
[Vuln-Report]マイター・コーポレーション「CVE-2019-1133」、国家脆弱性データベース、2020年8月、<https：//cve.mitre.org/cgi-bin/cvename.cgi?name = CVE-2019-11331>。
Acknowledgments
謝辞
The authors would like to thank (in alphabetical order) Ivan Arce, Roman Danyliw, Dhruv Dhody, Lars Eggert, Todd Glassey, Blake Hudson, Benjamin Kaduk, Erik Kline, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E. Miller, Bjorn Mork, Hal Murray, Francesca Palombini, Tomoyuki Sahara, Zaheduzzaman Sarker, Dieter Sibold, Steven Sommars, Jean St-Laurent, Kristof Teichel, Brian Trammell, Éric Vyncke, Ulrich Windl, and Dan Wing for providing valuable comments on earlier draft versions of this document.
著者らは、（アルファベット順に）イヴァン・アーク、Dhruv Dhody、Lars Egger、Lars Egger、Todd Glassey、Blake Hudson、Benjamin Kaduk、Aanchal Malhotra、Danny Mayer、Bjornムール、ハルマレー、フランチェスカパロンビニ、サハラ智之、ザヘデザマンサルー、ディエーターシモルズ、スティーブンソムラーズ、ジーンズセントローレント、テッケル、ブライアンのTrammell、éricvyncke、ウルリッヒwindl、そしてDan Wing windl、そしてDan Wing資料。
Watson Ladd raised the problem of DDoS mitigation when the NTP well-known port is employed as the client port (discussed in Section 3.3 of this document).
Watson Laddは、NTP周知のポートがクライアントポートとして採用されている場合（このドキュメントのセクション3.3で説明しています）。
The authors would like to thank Harlan Stenn for answering questions about a popular NTP implementation (see <https://www.nwtime.org>).
著者らは、人気のNTP実装に関する質問に答えるためにHarlan Stennに感謝します（<https：//www.nwtime.org>）。
Fernando Gont would like to thank Nelida Garcia and Jorge Oscar Gont for their love and support.
Fernandoは、Nelida GarciaとJorge Oscarの愛とサポートに感謝します。
Authors' Addresses
著者の住所
Fernando Gont SI6 Networks Evaristo Carriego 2644 1706 Haedo, Provincia de Buenos Aires Argentina
Fernando Gont Si 6 Networks Evaristo Carriego 2644 1706 Haedo、Provincia de Buenos Airesアルゼンチン
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Guillermo Gont SI6 Networks Evaristo Carriego 2644 1706 Haedo, Provincia de Buenos Aires Argentina
Guillermo Gont Si 6 Networks Evaristo Carriego 2644 1706 Haedo、Provincia de Buenos Airesアルゼンチン
Phone: +54 11 4650 8472
Email: ggont@si6networks.com
URI: https://www.si6networks.com
Miroslav Lichvar Red Hat Purkynova 115 612 00 Brno Czech Republic
Miroslav Lichvar Red Hat Purkynova 115 612 00ブルノチェコ共和国
Email: mlichvar@redhat.com