<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC5905 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"> <!ENTITY RFC6056 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6056.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY I-D.ietf-ntp-data-minimization SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ntp-data-minimization.xml"> <!ENTITY I-D.irtf-pearg-numeric-ids-generation SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-irtf-pearg-numeric-ids-generation-07.xml"> <!ENTITY RFC2663 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"> <!ENTITY RFC3715 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3715.xml"> <!ENTITY RFC4953 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4953.xml"> <!ENTITY RFC5927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5927.xml"> <!ENTITY RFC6335 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"> <!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"> ]>"rfc2629-xhtml.ent"> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ntp-port-randomization-08" number="9109" submissionType="IETF" category="std" consensus="true" updates="5905"ipr="trust200902"> <!-- Generated by id2xml 1.5.0 on 2021-06-30T00:34:10Z --> <?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc text-list-symbols="o*+-"?> <?rfc toc="yes"?>ipr="trust200902" obsoletes="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <front> <title abbrev="NTP PortRandomization">Port Randomization in the NetworkRandomization">Network Time Protocol Version4</title>4: Port Randomization</title> <seriesInfo name="RFC" value="9109"/> <author initials="F." surname="Gont" fullname="Fernando Gont"> <organization>SI6 Networks</organization><address><postal><street>Evaristo<address> <postal> <street>Evaristo Carriego 2644</street> <city>Haedo, Provincia de BuenosAires</city><code>1706</code>Aires</city> <code>1706</code> <country>Argentina</country> </postal> <phone>+54 11 4650 8472</phone> <email>fgont@si6networks.com</email> <uri>https://www.si6networks.com</uri> </address> </author> <author initials="G." surname="Gont" fullname="Guillermo Gont"> <organization>SI6 Networks</organization><address><postal><street>Evaristo<address> <postal> <street>Evaristo Carriego 2644</street> <city>Haedo, Provincia de BuenosAires</city><code>1706</code>Aires</city> <code>1706</code> <country>Argentina</country> </postal> <phone>+54 11 4650 8472</phone> <email>ggont@si6networks.com</email> <uri>https://www.si6networks.com</uri> </address> </author> <author initials="M." surname="Lichvar" fullname="Miroslav Lichvar"> <organization>Red Hat</organization><address><postal><street>Purkynova<address> <postal> <street>Purkynova 115</street><city>Brno</city><code>612<city>Brno</city> <code>612 00</code> <country>Czech Republic</country> </postal> <email>mlichvar@redhat.com</email> </address> </author> <date year="2021"month="June"/>month="August"/> <workgroup>Network Time Protocol (ntp) Working Group</workgroup><!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><t><keyword>security</keyword> <keyword>transport protocols</keyword> <abstract> <t> The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicitedpackets,packets and therefore require the use of a well-known port as the localport number.port. However, in the case of NTP modes where the use of awell- knownwell-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to performblind/ off-pathblind/off-path attacks. This document formally updatesRFC5905,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.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="sect-1"><t>anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> The Network Time Protocol (NTP) is one of the oldest Internetprotocols,protocols and is currently specified in <xreftarget="RFC5905"/>.target="RFC5905" format="default"/>. 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 <xreftarget="NTP-VULN"/>.target="NTP-VULN" format="default"/>. Some of these vulnerabilities allow foroff-path/blindblind/off-path attacks, where an attacker can send forged packets to one or both NTP peersfor achievingto achieve Denial of Service (DoS),time-shifts,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} (seesection 9.1 of<xreftarget="RFC5905"/>).target="RFC5905" sectionFormat="of" section="9.1"/>). Some of these parameters may beeasilyknown or easily guessed.</t> <t> NTP can operate in several modes. Some of these modes rely on the ability of nodes to receive unsolicitedpackets,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 ofan attackerattackers to perform blind/off-path attacks (since knowledge of the port numbers is typically required for such attacks). A recent study <xreftarget="NIST-NTP"/>target="NIST-NTP" format="default"/> that analyzes the port numbers employed by NTP clients suggests thata considerable number ofnumerous 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.</t> <t> BCP 156 <xreftarget="RFC6056"/>target="RFC6056" format="default"/> already recommends the randomization oftransport- protocoltransport-protocol ephemeral ports. This document aligns NTP with the recommendation in BCP 156 <xreftarget="RFC6056"/>,target="RFC6056" format="default"/> by formally updating <xreftarget="RFC5905"/>target="RFC5905" format="default"/> such that port randomization is employed for those NTP modes for which the use of the NTP well-known port is not needed.</t> </section> <sectiontitle="Terminology" anchor="sect-2"><t>anchor="sect-2" numbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119"/>target="RFC2119" format="default"/> <xreftarget="RFC8174"/>target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t> </section> <sectiontitle="Considerations Aboutanchor="sect-3" numbered="true" toc="default"> <name>Considerations about Port Randomization inNTP" anchor="sect-3"><t>NTP</name> <t> The following subsections analyze a number of considerations about transport-protocol ephemeral port randomization when applied to NTP.</t> <sectiontitle="Mitigation Against Off-path Attacks" anchor="sect-3.1"><t>anchor="sect-3.1" numbered="true" toc="default"> <name>Mitigation against Off-Path Attacks</name> <t> There has been a fair share of work in the area ofoff-path/blindblind/off-path attacks against transport protocols and upper-layer protocols, such as <xreftarget="RFC5927"/>target="RFC4953" format="default"/> and <xreftarget="RFC4953"/>.target="RFC5927" format="default"/>. Whether the target of the attack is atransport protocoltransport-protocol instance (e.g., TCP connection) or an upper-layer protocol instance (e.g., anapplication protocolapplication-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 targettransport protocoltransport-protocol instance or thetransport protocoltransport-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.</t> <t> 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 thetransport-layer.transport layer. This document aligns the NTP specification <xreftarget="RFC5905"/>target="RFC5905" format="default"/> with the existing best current practice on transport-protocol ephemeral port selection, irrespective of other techniques that may (and should) be implemented for mitigatingoff- pathoff-path attacks.</t> <t> We note that transport-protocol ephemeral port randomization is a transport-layer mitigation againstoff-path/blind attacks,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.(e.g., <xreftarget="I-D.ietf-ntp-data-minimization"/>).target="I-D.ietf-ntp-data-minimization" format="default"/>). For instance, some of the aforementioned mitigations may be ineffective against some off-path attacks <xreftarget="NTP-FRAG"/>target="NTP-FRAG" format="default"/> or may benefit from the additional entropy provided by port randomization <xreftarget="NTP-security"/>.</t>target="NTP-security" format="default"/>.</t> </section> <sectiontitle="Effectsanchor="sect-3.2" numbered="true" toc="default"> <name>Effects on PathSelection" anchor="sect-3.2"><t>Selection</name> <t> Intermediate systems implementing the Equal-CostMulti-PathMultipath (ECMP) algorithm may select the outgoing link by computing a hash over a number of values,that includeincluding the transport-protocol source port. Thus, as discussed in <xreftarget="NTP-CHLNG"/>,target="NTP-CHLNG" format="default"/>, the selected client port may have an influence on the measured offset and delay.</t> <t> 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.</t> <t> Network paths to/from a given server are less likely to change between requests if port randomization is applied on aper- associationper-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 theirclocksclocks. This is due to their NTP exchanges consistently taking different paths with different asymmetry in the network delay.</t> <t> <xreftarget="sect-4"/>target="sect-4" format="default"/> recommends that NTP implementationstorandomize 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.</t> </section> <sectiontitle="Filteringanchor="sect-3.3" numbered="true" toc="default"> <name>Filtering of NTPtraffic" anchor="sect-3.3"><t>Traffic</name> <t> In a number of scenarios (such as when mitigating DDoS attacks), a network operator may want to differentiate between NTP requests sent byclients,clients and NTP responses sent by NTP servers. If an implementation employs the NTP well-known port for the clientport number,port, requests/responses cannot be readily differentiated by inspecting the source and destination port numbers. Implementation of port randomization fornon-symmetricalnonsymmetrical modes allows for simple differentiation of NTP requests andresponses,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.</t> </section> <sectiontitle="Effectanchor="sect-3.4" numbered="true" toc="default"> <name>Effect on NAPTdevices" anchor="sect-3.4"><t>Devices</name> <t> 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) <xreftarget="RFC6335"/>target="RFC6335" format="default"/> 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.</t><t>NOTES: <list> <t> NAPT<aside> <t>NOTES:</t> <t indent="3">NAPT devices are defined inSection 4.1.2 of<xreftarget="RFC2663"/>.</t> <t>Thetarget="RFC2663" sectionFormat="of" section="4.1.2"/>.</t> <t indent="3">The reported behavior is similar to the special treatment of UDP port500 that500, which has been documented inSection 2.3 of<xreftarget="RFC3715"/>.</t> </list> </t>target="RFC3715" sectionFormat="of" section="2.3"/>.</t> </aside> <t> 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.</t> </section> </section> <sectiontitle="Updateanchor="sect-4" numbered="true" toc="default"> <name>Update toRFC5905" anchor="sect-4"><t>RFC 5905</name> <t> The following text from Section9.1 ("Peer<xref target="RFC5905" section="9.1" sectionFormat="bare">Peer ProcessVariables")Variables</xref> of <xref target="RFC5905"/>:</t><t><list style="hanging" hangIndent="3"> <t hangText="dstport:"><blockquote> <dl newline="false" spacing="normal" indent="3"> <dt>dstport:</dt> <dd> 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 thisassociation.</t> </list> </t>association.</dd> </dl> </blockquote> <t>is replaced with:</t><t><list style="hanging" hangIndent="3"> <t hangText="dstport:"><blockquote> <dl newline="false" spacing="normal" indent="3"> <dt>dstport:</dt> <dd> UDP port number of the client. In the case of broadcast server mode (5) and symmetric modes (1 and 2), itSHOULD<bcp14>SHOULD</bcp14> contain the NTP port number PORT (123) assigned bytheIANA. In the client mode (3), itSHOULD<bcp14>SHOULD</bcp14> contain a randomized port number, as specified in <xreftarget="RFC6056"/>.target="RFC6056" format="default"/>. The value in this variable becomes the source port number of packets sent from this association. The randomized port numberSHOULD NOT<bcp14>SHOULD NOT</bcp14> be shared with other associations, to avoid revealing the randomized port to otherassociations.</t> <t>Ifassociations.</dd> <dt/> <dd>If a client implementation performs transport-protocol ephemeral port randomization on a per-request basis, itSHOULD<bcp14>SHOULD</bcp14> close the correspondingsocket/ portsocket/port after each request/response exchange. In order to prevent duplicate or delayed server packets from eliciting ICMP port unreachable error messages <xref target="RFC0792"/> <xref target="RFC4443"/> at the client, the clientMAY<bcp14>MAY</bcp14> wait for more responses from the server for a specific period of time(e.g.(e.g., 3 seconds) before closing the UDPsocket/port.</t> </list> </t> <t>NOTES:</t>socket/port.</dd> <dt/> <dd/> </dl> <dl newline="false" spacing="normal" indent="6"> <dt/><dd><t>NOTES:</t> <t>Randomizing the ephemeral port number on a per-request basis will better mitigateoff-path/blindblind/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 timemeasurement.</t> <t>Onmeasurement.</t></dd> <dt/> <dd>On most current operating systems, which implement ephemeral port randomization <xreftarget="RFC6056"/>,target="RFC6056" format="default"/>, 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*<em>not</em> binding the socket with the bind()function,function or binding it to port 0, which has a special meaning of "any port".connect()ingUsing 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 theapplication).</t>application).</dd> </dl> </blockquote> </section> <sectiontitle="Implementation Status" anchor="sect-5"><t> [RFC Editor: Please remove this section before publication of this document as an RFC.]</t>anchor="sect-6" numbered="true" toc="default"> <name>IANA Considerations</name> <t> Thissection records the statusdocument has no IANA actions.</t> </section> <section anchor="sect-7" numbered="true" toc="default"> <name>Security Considerations</name> <t> The security implications ofknown implementationspredictable numeric identifiers <xref target="I-D.irtf-pearg-numeric-ids-generation" format="default"/> (and of predictable transport-protocol port numbers <xref target="RFC6056" format="default"/> in particular) have been known for a long time now. However, theprotocol defined by thisNTP specificationat the time of posting of this Internet-Draft, and is based onhas traditionally followed aproposal describedpattern of employing common settings even when not strictly necessary, which at times has resulted in negative security and privacy implications (see, e.g., <xreftarget="RFC7942"/>.target="I-D.ietf-ntp-data-minimization" format="default"/>). Thedescriptionuse ofimplementations in this section is intended to assisttheIETF in its decision processes in progressing drafts to RFCs. Please note thatNTP well-known port (123) for thelisting of any individual implementation here doessrcport and dstport variables is notimply endorsement byrequired for all operating modes. Such unnecessary usage comes at theIETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.</t> <t><list style="hanging" hangIndent="3"> <t hangText="OpenNTPD:"> <xref target="OpenNTPD"/> has never explicitly set the local port of NTP clients, and thus employs the ephemeral port selection algorithm implemented by the operating system. Thus, on all operating systems that implement port randomization (such as current versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ port randomization for client ports. </t> <t hangText="chrony:"> <xref target="chrony"/> by default does not set the local client port, and thus employs the ephemeral port selection algorithm implemented by the operating system. Thus, on all operating systems that implement port randomization (such as current versions of OpenBSD, Linux, and FreeBSD), chrony will employ port randomization for client ports. </t> <t hangText="nwtime.org's sntp client:"> sntp does not explicitly set the local port, and thus employs the ephemeral port selection algorithm implemented by the operating system. Thus, on all operating systems that implement port randomization (such as current versions of OpenBSD, Linux, and FreeBSD), it will employ port randomization for client ports. </t> </list> </t> </section> <section title="IANA Considerations" anchor="sect-6"><t> There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC.</t> </section> <section title="Security Considerations" anchor="sect-7"><t> The security implications of predictable numeric identifiers <xref target="I-D.irtf-pearg-numeric-ids-generation"/> (and of predictable transport-protocol port numbers <xref target="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. <xref target="I-D.ietf-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 reducingexpense of reducing the amount of work required for an attacker to successfully performoff-path/blindblind/off-path attacks against NTP. Therefore, this document formally updates <xreftarget="RFC5905"/>,target="RFC5905" format="default"/>, recommending the use oftransport- protocoltransport-protocol port randomization when use of the NTP well-known port is not required.</t> <t> This issue has been assigned CVE-2019-11331 <xreftarget="VULN-REPORT"/>target="VULN-REPORT" format="default"/> in the U.S. National Vulnerability Database (NVD).</t> </section><section title="Acknowledgments" anchor="sect-8"><t> 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, Eric Vyncke, Ulrich Windl, and Dan Wing, for providing valuable comments on earlier versions of this document.</t> <t> 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).</t> <t> The authors would like to thank Harlan Stenn for answering questions about nwtime.org's NTP implementation.</t> <t> Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for their love and support.</t> </section></middle> <back><references title="Normative References"> &RFC2119; &RFC5905; &RFC6056; &RFC8174;<displayreference target="I-D.ietf-ntp-data-minimization" to="NTP-DATA-MINIMIZATION"/> <displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="PEARG-NUMERIC-IDS"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6056.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references><references title="Informative References"><references> <name>Informative References</name> <referenceanchor="chrony" target="https://chrony.tuxfamily.org/"><front> <title>chrony</title> <author>anchor='I-D.ietf-ntp-data-minimization'> <front> <title>NTP Client Data Minimization</title> <author initials='D' surname='Franke' fullname='Daniel Franke'> <organization /> </author><date/><author initials='A' surname='Malhotra' fullname='Aanchal Malhotra'> <organization /> </author> <date month='March' day='25' year='2019' /> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-ntp-data-minimization-04' /> <format type='TXT' target='http://www.ietf.org/internet-drafts/draft-ietf-ntp-data-minimization-04.txt' /> </reference>&I-D.ietf-ntp-data-minimization; &I-D.irtf-pearg-numeric-ids-generation;<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-pearg-numeric-ids-generation.xml"/> <reference anchor="NIST-NTP"target="https://tf.nist.gov/general/pdf/2818.pdf"><front>target="https://tf.nist.gov/general/pdf/2818.pdf"> <front> <title>Usage Analysis of the NIST Internet Time Service</title> <author initials="J." surname="Sherman"fullname="J.fullname="Jeffrey Sherman"> </author> <author initials="J." surname="Levine"fullname="J.fullname="Judah Levine"> </author> <date month="March" year="2016"/> </front> <seriesInfoname="Journal" value="ofname="DOI" value="10.6028/jres.121.003"/> <refcontent>Journal of Research of the National Institute of Standards andTechnologyTechnology, Volume121"/>121</refcontent> </reference> <reference anchor="NTP-CHLNG"target="http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf"><front>target="http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf"> <front> <title>Challenges in Time TransferUsingusing the Network Time Protocol (NTP)</title> <author initials="S." surname="Sommars"fullname="S.fullname="Steven Sommars"> </author> <date month="January" year="2017"/> </front> <seriesInfoname="Proceedings" value="ofname="DOI" value="10.33012/2017.14978"/> <refcontent>Proceedings of the 48th Annual Precise Time and Time Interval Systems and ApplicationsMeeting"/>Meeting, pp. 271-290</refcontent> </reference> <reference anchor="NTP-FRAG"target="https://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf"><front>target="https://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf"> <front> <title>Attacking the Network Time Protocol</title> <author initials="A." surname="Malhotra"fullname="A.fullname="Aanchal Malhotra"> </author> <author initials="I." surname="Cohen"fullname="I.fullname="Isaac Cohen"> </author> <author initials="E." surname="Brakke"fullname="E.fullname="Erik Brakke"> </author> <author initials="S." surname="Goldberg"fullname="S.fullname="Sharon Goldberg"> </author> <datemonth="Feb" year="2017"/>month="February" year="2016"/> </front> <seriesInfo name="DOI" value="10.14722/ndss.2016.23090"/> <refcontent>NDSS '16</refcontent> </reference> <reference anchor="NTP-security"target="https://eprint.iacr.org/2016/1006"><front>target="https://eprint.iacr.org/2016/1006.pdf"> <front> <title>The Security of NTP's Datagram Protocol</title> <author initials="A." surname="Malhotra"fullname="A.fullname="Aanchal Malhotra"> </author> <author initials="M." surname="Van Gundy"fullname="M.fullname="Matthew Van Gundy"> </author> <authorinitials="V."initials="M." surname="Varia"fullname="V.fullname="Mayank Varia"> </author> <author initials="H." surname="Kennedy"fullname="H.fullname="Haydn Kennedy"> </author> <author initials="J." surname="Gardner"fullname="J.fullname="Jonathan Gardner"> </author> <author initials="S." surname="Goldberg"fullname="S.fullname="Sharon Goldberg"> </author> <dateyear="2016"/>year="2017" month="February"/> </front> <seriesInfoname="Cryptology" value="ePrintname="DOI" value="10.1007/978-3-319-70972-7_23"/> <refcontent>Cryptology ePrint Archive Report2016/1006"/>2016/1006</refcontent> </reference> <reference anchor="NTP-VULN"target="https://support.ntp.org/bin/view/Main/SecurityNotice"><front>target="http://support.ntp.org/bin/view/Main/SecurityNotice"> <front> <title>Network Time Foundation</title> <author> </author> <date/> </front> </reference><reference anchor="OpenNTPD" target="https://www.openntpd.org"><front> <title>OpenNTPD Project</title> <author> </author> <date/> </front> </reference> &RFC2663; &RFC3715; &RFC4953; &RFC5927; &RFC6335; &RFC7942;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3715.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4953.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5927.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <reference anchor="VULN-REPORT"target="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11331"><front> <title>CVE-2019-11331</title>target="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11331"> <front> <title>CVE-2019-1133</title> <author> <organization>The MITRE Corporation</organization> </author> <datemonth="April" year="2019"/>month="August" year="2020"/> </front> <refcontent>National Vulnerability Database</refcontent> </reference> </references> </references> <section anchor="sect-8" numbered="false" toc="default"> <name>Acknowledgments</name> <t> The authors would like to thank (in alphabetical order) <contact fullname="Ivan Arce"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Todd Glassey"/>, <contact fullname="Blake Hudson"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Watson Ladd"/>, <contact fullname="Aanchal Malhotra"/>, <contact fullname="Danny Mayer"/>, <contact fullname="Gary E. Miller"/>, <contact fullname="Bjorn Mork"/>, <contact fullname="Hal Murray"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Tomoyuki Sahara"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Dieter Sibold"/>, <contact fullname="Steven Sommars"/>, <contact fullname="Jean St-Laurent"/>, <contact fullname="Kristof Teichel"/>, <contact fullname="Brian Trammell"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Ulrich Windl"/>, and <contact fullname="Dan Wing"/> for providing valuable comments on earlier draft versions of this document.</t> <t> <contact fullname="Watson Ladd"/> raised the problem of DDoS mitigation when the NTP well-known port is employed as the client port (discussed in <xref target="sect-3.3"/> of this document).</t> <t> The authors would like to thank <contact fullname="Harlan Stenn"/> for answering questions about a popular NTP implementation (see <eref target="https://www.nwtime.org" brackets="angle"/>).</t> <t> <contact fullname="Fernando Gont"/> would like to thank <contact fullname="Nelida Garcia"/> and <contact fullname="Jorge Oscar Gont"/> for their love and support.</t> </section> </back> </rfc>