<?xml version='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">

<rfc submissionType="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 Port Randomization">Port Randomization in the Network Randomization">Network Time Protocol Version 4</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 Buenos Aires</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 Buenos Aires</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 unsolicited packets, packets and therefore
   require the use of a well-known port as the local port
   number. port.  However, in
   the case of NTP modes where the use of a well-
   known well-known port is not required,
   employing such a well-known port unnecessarily facilitates the ability of
   attackers to perform blind/
   off-path blind/off-path attacks. This document formally
   updates RFC5905, 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>
    <section title="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 Internet
   protocols,
   protocols and is currently specified in <xref target="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 <xref target="NTP-VULN"/>. target="NTP-VULN" format="default"/>.  Some of these
   vulnerabilities allow for off-path/blind blind/off-path attacks, where an attacker
   can send forged packets to one or both NTP peers for achieving to 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} (see section 9.1 of <xref target="RFC5905"/>). target="RFC5905" sectionFormat="of" section="9.1"/>).
   Some of these parameters may be easily known or easily guessed.</t>
      <t>
   NTP can operate in several modes.  Some of these modes rely on the
   ability of nodes to receive unsolicited packets, 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 an attacker attackers
   to perform blind/off-path attacks (since knowledge of the port
   numbers is typically required for such attacks).  A recent study
   <xref target="NIST-NTP"/> target="NIST-NTP" format="default"/> that analyzes the port numbers employed by NTP clients
   suggests that a considerable number of 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.</t>
      <t>
   BCP 156 <xref target="RFC6056"/> target="RFC6056" format="default"/> already recommends the randomization of transport-
   protocol transport-protocol ephemeral ports.  This document aligns NTP with the
   recommendation in BCP 156 <xref target="RFC6056"/>, target="RFC6056" format="default"/> by formally updating <xref target="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>
    <section title="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 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only when, they appear in all
   capitals, as shown here.</t>
    </section>
    <section title="Considerations About anchor="sect-3" numbered="true" toc="default">
      <name>Considerations about Port Randomization in NTP" 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>
      <section title="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 of off-path/blind blind/off-path
   attacks against transport protocols and upper-layer protocols, such
   as <xref target="RFC5927"/> target="RFC4953" format="default"/> and <xref target="RFC4953"/>. target="RFC5927" format="default"/>.  Whether the target of the attack is a
   transport protocol
   transport-protocol instance (e.g., TCP connection) or an upper-layer
   protocol instance (e.g., an application protocol 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 transport-protocol instance or the
   transport protocol
   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.</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 the transport-layer. transport layer.  This document
   aligns the NTP specification <xref target="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 mitigating off-
   path off-path attacks.</t>
        <t>
   We note that transport-protocol ephemeral port randomization is a
   transport-layer mitigation against off-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.,
   <xref target="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 <xref target="NTP-FRAG"/> target="NTP-FRAG" format="default"/> or may benefit from the additional entropy
   provided by port randomization <xref target="NTP-security"/>.</t> target="NTP-security" format="default"/>.</t>
      </section>
      <section title="Effects anchor="sect-3.2" numbered="true" toc="default">
        <name>Effects on Path Selection" anchor="sect-3.2"><t> Selection</name>
        <t>
   Intermediate systems implementing the Equal-Cost Multi-Path Multipath (ECMP)
   algorithm may select the outgoing link by computing a hash over a
   number of values, that include including the transport-protocol source port.
   Thus, as discussed in <xref target="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 a per-
   association 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 clocks.
   This is due to their NTP exchanges consistently taking different paths with
   different asymmetry in the network delay.</t>
        <t>
   <xref target="sect-4"/> target="sect-4" format="default"/> recommends that NTP implementations to 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.</t>
      </section>
      <section title="Filtering anchor="sect-3.3" numbered="true" toc="default">
        <name>Filtering of NTP traffic" 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
   by clients, clients and NTP responses sent by NTP servers.  If an
   implementation employs the NTP well-known port for the client port
   number, port, requests/responses cannot be readily differentiated by
   inspecting the source and destination port numbers.

   Implementation of port randomization for non-symmetrical nonsymmetrical modes allows for
   simple differentiation of NTP requests and responses, 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>
      <section title="Effect anchor="sect-3.4" numbered="true" toc="default">
        <name>Effect on NAPT devices" 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) <xref target="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 in Section 4.1.2 of <xref target="RFC2663"/>.</t>

	<t>The target="RFC2663" sectionFormat="of" section="4.1.2"/>.</t>
        <t indent="3">The reported behavior is similar to the special treatment of UDP
      port 500 that 500, which has been documented in Section 2.3 of <xref target="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>
    <section title="Update anchor="sect-4" numbered="true" toc="default">
      <name>Update to RFC5905" anchor="sect-4"><t> RFC 5905</name>
      <t>
   The following text from Section 9.1 ("Peer
      <xref target="RFC5905" section="9.1" sectionFormat="bare">Peer
Process Variables") 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 this association.</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), it SHOULD <bcp14>SHOULD</bcp14> contain
      the NTP port number PORT (123) assigned by the IANA.  In the
      client mode (3), it SHOULD <bcp14>SHOULD</bcp14> contain a randomized port number, as
      specified in <xref target="RFC6056"/>. target="RFC6056" format="default"/>.  The value in this variable becomes the
      source port number of packets sent from this association.  The
      randomized port number SHOULD NOT <bcp14>SHOULD NOT</bcp14> be shared with other
      associations, to avoid revealing the randomized port to other
      associations.</t>

	<t>If
      associations.</dd>
        <dt/>
        <dd>If a client implementation performs transport-protocol ephemeral port randomization
        on a per-request basis, it SHOULD <bcp14>SHOULD</bcp14> close the corresponding socket/
      port socket/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 client MAY <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 UDP socket/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 mitigate off-path/blind 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.</t>

	 <t>On measurement.</t></dd>
        <dt/>
         <dd>On most current operating systems, which implement ephemeral
         port randomization <xref target="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()ing 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).</t> application).</dd>
         </dl>
        </blockquote>

    </section>
    <section title="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>
This section records the status document has no IANA actions.</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The security implications of known implementations predictable 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, the
   protocol defined by this NTP specification at the time of posting of this
   Internet-Draft, and is based on has
   traditionally followed a proposal described 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="RFC7942"/>. target="I-D.ietf-ntp-data-minimization" format="default"/>).  The description use of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that NTP well-known
   port (123) for the listing of any individual implementation
   here does srcport and dstport variables is not imply endorsement by required for
   all operating modes.  Such unnecessary usage comes at the IETF.  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
   reducing expense of
   reducing the amount of work required for an attacker to successfully
   perform off-path/blind blind/off-path attacks against NTP.  Therefore, this document
   formally updates <xref target="RFC5905"/>, target="RFC5905" format="default"/>, recommending the use of transport-
   protocol transport-protocol port randomization when use of the NTP well-known port is
   not required.</t>
      <t>
   This issue has been assigned CVE-2019-11331 <xref target="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>

<reference anchor="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>
	  <seriesInfo name="Journal" value="of name="DOI" value="10.6028/jres.121.003"/>
          <refcontent>Journal of Research of the National Institute of Standards and Technology Technology, Volume 121"/> 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 Transfer Using using the Network Time Protocol (NTP)</title>
            <author initials="S." surname="Sommars" fullname="S. fullname="Steven Sommars">
	</author>
            <date month="January" year="2017"/>
          </front>
<seriesInfo name="Proceedings" value="of name="DOI" value="10.33012/2017.14978"/>
          <refcontent>Proceedings of the 48th Annual Precise Time and Time Interval Systems and Applications Meeting"/> 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>
            <date month="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>
            <author initials="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>
            <date year="2016"/> year="2017" month="February"/>
          </front>
          <seriesInfo name="Cryptology" value="ePrint name="DOI" value="10.1007/978-3-319-70972-7_23"/>
<refcontent>Cryptology ePrint Archive Report 2016/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>
            <date month="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>