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.

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. 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.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 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.

The Network Time Protocol (NTP) is one of the oldest Internet protocols and is currently specified in [RFC 5905]. 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 RFC 5905). Some of these parameters may be known or easily guessed. 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. BCP 156 [RFC 6056] already recommends the randomization of transport-protocol ephemeral ports. This document aligns NTP with the recommendation in BCP 156 [RFC 6056] by formally updating [RFC 5905] such that port randomization is employed for those NTP modes for which the use of the NTP well-known port is not needed.

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

The following subsections analyze a number of considerations about transport-protocol ephemeral port randomization when applied to 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 [RFC 4953] and [RFC 5927]. 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. 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 [RFC 5905] 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. 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].

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. 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. 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.

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.

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) [RFC 6335] 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. 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.

The following text from Section 9.1 of [RFC 5905]:

---

---

is replaced with:

---

---

This document has no IANA actions.

The security implications of predictable numeric identifiers [PEARG-NUMERIC-IDS] (and of predictable transport-protocol port numbers [RFC 6056] 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 [RFC 5905], recommending the use of transport-protocol port randomization when use of the NTP well-known port is not required. This issue has been assigned CVE-2019-11331 [VULN-REPORT] in the U.S. National Vulnerability Database (NVD).

[RFC2119]

S. Bradner, "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>.

[RFC5905]

D. Mills, J. Martin, J. Burbank, 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>.

[RFC6056]

M. Larsen, 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>.

[RFC8174]

B. Leiba, "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>.

[NIST-NTP]

J. Sherman, and J. Levine, "Usage Analysis of the NIST Internet Time Service", DOI 10.6028/jres.121.003, March 2016,
<https://tf.nist.gov/general/pdf/2818.pdf>.

[NTP-CHLNG]

S. Sommars, "Challenges in Time Transfer using the Network Time Protocol (NTP)", DOI 10.33012/2017.14978, January 2017,
<http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf>.

[NTP-DATA-MINIMIZATION]

D Franke, and A Malhotra, "NTP Client Data Minimization", Internet-Draft draft-ietf-ntp-data-minimization-04, March 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization-04>.

[NTP-FRAG]

A. Malhotra, I. Cohen, E. Brakke, and S. Goldberg, "Attacking the Network Time Protocol", DOI 10.14722/ndss.2016.23090, February 2016,
<https://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf>.

[NTP-security]

A. Malhotra, M. Van Gundy, M. Varia, H. Kennedy, J. Gardner, and S. Goldberg, "The Security of NTP's Datagram Protocol", DOI 10.1007/978-3-319-70972-7_23, February 2017,
<https://eprint.iacr.org/2016/1006.pdf>.

[NTP-VULN]

"Network Time Foundation",
<http://support.ntp.org/bin/view/Main/SecurityNotice>.

[PEARG-NUMERIC-IDS]

Quarkslab, , and , "On the Generation of Transient Numeric Identifiers", Internet-Draft draft-irtf-pearg-numeric-ids-generation-07, February 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-07>.

[RFC0792]

J. Postel, "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.

[RFC2663]

P. Srisuresh, 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>.

[RFC3715]

B. Aboba, 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>.

[RFC4443]

A. Conta, S. Deering, and M. Gupta, "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>.

[RFC4953]

J. Touch, "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>.

[RFC5927]

F. Gont, "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/info/rfc5927>.

[RFC6335]

M. Cotton, L. Eggert, J. Touch, M. Westerlund, 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>.

[VULN-REPORT]

The MITRE Corporation, "CVE-2019-1133", August 2020,
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11331>.

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. 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). The authors would like to thank Harlan Stenn for answering questions about a popular NTP implementation (see <https://www.nwtime.org>). Fernando Gont would like to thank Nelida Garcia and Jorge Oscar Gont for their love and support.

Fernando Gont

Guillermo Gont

Miroslav Lichvar