Diff: rfc9109xml2.original.xml

	rfc9109xml2.original.xml	rfc9109.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2119.xml">
	<!ENTITY RFC5905 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5905.xml">
	<!ENTITY RFC6056 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6056.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.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.RF
	C.2663.xml">
	<!ENTITY RFC3715 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.3715.xml">
	<!ENTITY RFC4953 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4953.xml">
	<!ENTITY RFC5927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5927.xml">
	<!ENTITY RFC6335 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6335.xml">
	<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7942.xml">
	]>
	<rfc submissionType="IETF" docName="draft-ietf-ntp-port-randomization-08" catego
	ry="std" 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"?>
	<front>
	<title abbrev="NTP Port Randomization">Port Randomization in the Network
	Time Protocol Version 4</title>
	<author initials="F." surname="Gont" fullname="Fernando Gont">
	<organization>SI6 Networks</organization>
	<address><postal><street>Evaristo Carriego 2644</street>
	<city>Haedo, Provincia de Buenos 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 Carriego 2644</street>
	<city>Haedo, Provincia de Buenos 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 115</street>
	<city>Brno</city><code>612 00</code>
	<country>Czech Republic</country>
	</postal>
	<email>mlichvar@redhat.com</email>
	</address>
	</author>

	<date year="2021" month="June"/>
	<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. -->	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">


	<keyword>example</keyword>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ntp-port-ran domization-08" number="9109" submissionType="IETF" category="std" consensus="tru e" updates="5905" ipr="trust200902" obsoletes="" xml:lang="en" symRefs="true" so rtRefs="true" tocInclude="true" version="3">


	<abstract><t>	<front>
	The Network Time Protocol 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
	number. However, in the case of NTP modes where the use of a well-
	known port is not required, employing such well-known port
	unnecessarily facilitates the ability of attackers to perform blind/
	off-path attacks. This document formally updates RFC5905,
	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>	<title abbrev="NTP Port Randomization">Network Time Protocol Version 4: Port
	</front>	Randomization</title>
		<seriesInfo name="RFC" value="9109"/>
		<author initials="F." surname="Gont" fullname="Fernando Gont">
		<organization>SI6 Networks</organization>
		<address>
		<postal>
		<street>Evaristo Carriego 2644</street>
		<city>Haedo, Provincia de Buenos 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 Carriego 2644</street>
		<city>Haedo, Provincia de Buenos 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 115</street>
		<city>Brno</city>
		<code>612 00</code>
		<country>Czech Republic</country>
		</postal>
		<email>mlichvar@redhat.com</email>
		</address>
		</author>
		<date year="2021" month="August"/>
		<workgroup>Network Time Protocol (ntp) Working Group</workgroup>
		<keyword>security</keyword>
		<keyword>transport protocols</keyword>


	<middle>	<abstract>
	<section title="Introduction" anchor="sect-1"><t>	<t>
		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.</t>
		</abstract>
		</front>
		<middle>
		<section anchor="sect-1" numbered="true" toc="default">
		<name>Introduction</name>
		<t>
	The Network Time Protocol (NTP) is one of the oldest Internet	The Network Time Protocol (NTP) is one of the oldest Internet

	protocols, and currently specified in <xref target="RFC5905"/>. Since its or iginal	protocols and is currently specified in <xref target="RFC5905" format="defaul t"/>. Since its original
	implementation, standardization, and deployment, a number of	implementation, standardization, and deployment, a number of
	vulnerabilities have been found both in the NTP specification and in	vulnerabilities have been found both in the NTP specification and in

	some of its implementations <xref target="NTP-VULN"/>. Some of these	some of its implementations <xref target="NTP-VULN" format="default"/>. Some
	vulnerabilities allow for off-path/blind attacks, where an attacker	of these
	can send forged packets to one or both NTP peers for achieving Denial	vulnerabilities allow for blind/off-path attacks, where an attacker
	of Service (DoS), time-shifts, or other undesirable outcomes. Many	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	of these attacks require the attacker to guess or know at least a
	target NTP association, typically identified by the tuple {srcaddr,	target NTP association, typically identified by the tuple {srcaddr,

	srcport, dstaddr, dstport, keyid} (see section 9.1 of <xref target="RFC5905"/	srcport, dstaddr, dstport, keyid} (see <xref target="RFC5905" sectionFormat="
	>).	of" section="9.1"/>).
	Some of these parameters may be easily known or guessed.</t>	Some of these parameters may be known or easily guessed.</t>
		<t>
	<t>
	NTP can operate in several modes. Some of these modes rely on the	NTP can operate in several modes. Some of these modes rely on the

	ability of nodes to receive unsolicited packets, and therefore	ability of nodes to receive unsolicited packets and therefore
	require the use of the NTP well-known port (123). However, for modes	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	where the use of a well-known port is not required, employing the
	well-known port unnecessarily facilitates the ability of an attacker	NTP well-known port unnecessarily facilitates the ability of attackers
	to perform blind/off-path attacks (since knowledge of the port	to perform blind/off-path attacks (since knowledge of the port
	numbers is typically required for such attacks). A recent study	numbers is typically required for such attacks). A recent study

	<xref target="NIST-NTP"/> that analyzes the port numbers employed by NTP clie	<xref target="NIST-NTP" format="default"/> that analyzes the port numbers emp
	nts	loyed by NTP clients
	suggests that a considerable number of NTP clients employ the NTP	suggests that numerous NTP clients employ the NTP well-known port as their lo
	well-known port as their local port, or select predictable ephemeral	cal port, or select predictable ephemeral
	port numbers, thus unnecessarily facilitating the ability of	port numbers, thus unnecessarily facilitating the ability of
	attackers to perform blind/off-path attacks against NTP.</t>	attackers to perform blind/off-path attacks against NTP.</t>

		<t>
	<t>	BCP 156 <xref target="RFC6056" format="default"/> already recommends the rand
	BCP 156 <xref target="RFC6056"/> already recommends the randomization of tran	omization of transport-protocol ephemeral ports. This document aligns NTP with
	sport-	the
	protocol ephemeral ports. This document aligns NTP with the	recommendation in BCP 156 <xref target="RFC6056" format="default"/> by formal
	recommendation in BCP 156 <xref target="RFC6056"/>, by formally updating <xre	ly updating <xref target="RFC5905" format="default"/>
	f target="RFC5905"/>
	such that port randomization is employed for those NTP modes for	such that port randomization is employed for those NTP modes for
	which the use of the NTP well-known port is not needed.</t>	which the use of the NTP well-known port is not needed.</t>

		</section>
	</section>	<section anchor="sect-2" numbered="true" toc="default">
		<name>Terminology</name>
	<section title="Terminology" anchor="sect-2"><t>	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in BCP	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bc
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the	p14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
	y appear in all	"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described
		in BCP
		14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d
		efault"/> when, and only when, they appear in all
	capitals, as shown here.</t>	capitals, as shown here.</t>

		</section>
	</section>	<section anchor="sect-3" numbered="true" toc="default">
		<name>Considerations about Port Randomization in NTP</name>
	<section title="Considerations About Port Randomization in NTP" anchor="s	<t>
	ect-3"><t>
	The following subsections analyze a number of considerations about	The following subsections analyze a number of considerations about
	transport-protocol ephemeral port randomization when applied to NTP.</t>	transport-protocol ephemeral port randomization when applied to NTP.</t>

		<section anchor="sect-3.1" numbered="true" toc="default">
	<section title="Mitigation Against Off-path Attacks" anchor="sect-3.1"><t	<name>Mitigation against Off-Path Attacks</name>
	>	<t>
	There has been a fair share of work in the area of off-path/blind	There has been a fair share of work in the area of blind/off-path
	attacks against transport protocols and upper-layer protocols, such	attacks against transport protocols and upper-layer protocols, such

	as <xref target="RFC5927"/> and <xref target="RFC4953"/>. Whether the target	as <xref target="RFC4953" format="default"/> and <xref target="RFC5927" forma
	of the attack is a	t="default"/>. Whether the target of the attack is a
	transport protocol instance (e.g., TCP connection) or an upper-layer	transport-protocol instance (e.g., TCP connection) or an upper-layer
	protocol instance (e.g., an application protocol instance), the	protocol instance (e.g., an application-protocol instance), the
	attacker is required to know or guess the five-tuple {Protocol, IP	attacker is required to know or guess the five-tuple {Protocol, IP
	Source Address, IP Destination Address, Source Port, Destination	Source Address, IP Destination Address, Source Port, Destination

	Port} that identifies the target transport protocol instance or the	Port} that identifies the target transport-protocol instance or the
	transport protocol instance employed by the target upper-layer	transport-protocol instance employed by the target upper-layer
	protocol instance. Therefore, increasing the difficulty of guessing	protocol instance. Therefore, increasing the difficulty of guessing
	this five-tuple helps mitigate blind/off-path attacks.</t>	this five-tuple helps mitigate blind/off-path attacks.</t>

		<t>
	<t>
	As a result of these considerations, transport-protocol ephemeral	As a result of these considerations, transport-protocol ephemeral
	port randomization is a best current practice (BCP 156) that helps	port randomization is a best current practice (BCP 156) that helps

	mitigate off-path attacks at the transport-layer. This document	mitigate off-path attacks at the transport layer. This document
	aligns the NTP specification <xref target="RFC5905"/> with the existing best	aligns the NTP specification <xref target="RFC5905" format="default"/> with t
	current	he existing best current
	practice on ephemeral port selection, irrespective of other	practice on transport-protocol ephemeral port selection, irrespective of othe
	techniques that may (and should) be implemented for mitigating off-	r
	path attacks.</t>	techniques that may (and should) be implemented for mitigating off-path attac
		ks.</t>
	<t>	<t>
	We note that transport-protocol ephemeral port randomization is a	We note that transport-protocol ephemeral port randomization is a

	transport-layer mitigation against off-path/blind attacks, and does	transport-layer mitigation against blind/off-path attacks and does
	not preclude (nor is it precluded by) other possible mitigations for	not preclude (nor is it precluded by) other possible mitigations for

	off-path attacks that might be implemented at other layers (e.g.	off-path attacks that might be implemented at other layers (e.g.,
	<xref target="I-D.ietf-ntp-data-minimization"/>). For instance, some of the	<xref target="I-D.ietf-ntp-data-minimization" format="default"/>). For insta
		nce, some of the
	aforementioned mitigations may be ineffective against some off-path	aforementioned mitigations may be ineffective against some off-path

	attacks <xref target="NTP-FRAG"/> or may benefit from the additional entropy	attacks <xref target="NTP-FRAG" format="default"/> or may benefit from the ad
	provided by port randomization <xref target="NTP-security"/>.</t>	ditional entropy
		provided by port randomization <xref target="NTP-security" format="default"/>
	</section>	.</t>
		</section>
	<section title="Effects on Path Selection" anchor="sect-3.2"><t>	<section anchor="sect-3.2" numbered="true" toc="default">
	Intermediate systems implementing the Equal-Cost Multi-Path (ECMP)	<name>Effects on Path Selection</name>
		<t>
		Intermediate systems implementing the Equal-Cost Multipath (ECMP)
	algorithm may select the outgoing link by computing a hash over a	algorithm may select the outgoing link by computing a hash over a

	number of values, that include the transport-protocol source port.	number of values, including the transport-protocol source port.
	Thus, as discussed in <xref target="NTP-CHLNG"/>, the selected client port ma	Thus, as discussed in <xref target="NTP-CHLNG" format="default"/>, the select
	y have	ed client port may have
	an influence on the measured offset and delay.</t>	an influence on the measured offset and delay.</t>

		<t>
	<t>
	If the source port is changed with each request, packets in different	If the source port is changed with each request, packets in different
	exchanges will be more likely to take different paths, which could	exchanges will be more likely to take different paths, which could
	cause the measurements to be less stable and have a negative impact	cause the measurements to be less stable and have a negative impact
	on the stability of the clock.</t>	on the stability of the clock.</t>

		<t>


	<t>	Network paths to/from a given server are less likely to change between
	Network paths to/from a given server are less likely to change	requests if port randomization is applied on a per-association basis. This
	between requests if port randomization is applied on a per-	approach minimizes the impact on the stability of NTP measurements,
	association basis. This approach minimizes the impact on the	but it may cause different clients in the same network synchronized to the
	stability of NTP measurements, but may cause different clients in the	same NTP server to have a significant stable offset between their clocks.
	same network synchronized to the same NTP server to have a	This is due to their NTP exchanges consistently taking different paths with
	significant stable offset between their clocks due to their NTP	different asymmetry in the network delay.</t>
	exchanges consistently taking different paths with different	<t>
	asymmetry in the network delay.</t>	<xref target="sect-4" format="default"/> recommends that NTP implementations
		randomize the ephemeral
	<t>
	<xref target="sect-4"/> recommends NTP implementations to randomize the ephem
	eral
	port number of client/server associations. The choice of whether to	port number of client/server associations. The choice of whether to
	randomize the port number on a per-association or a per-request basis	randomize the port number on a per-association or a per-request basis
	is left to the implementation.</t>	is left to the implementation.</t>

		</section>
	</section>	<section anchor="sect-3.3" numbered="true" toc="default">
		<name>Filtering of NTP Traffic</name>
	<section title="Filtering of NTP traffic" anchor="sect-3.3"><t>	<t>
	In a number of scenarios (such as when mitigating DDoS attacks), a	In a number of scenarios (such as when mitigating DDoS attacks), a
	network operator may want to differentiate between NTP requests sent	network operator may want to differentiate between NTP requests sent

	by clients, and NTP responses sent by NTP servers. If an	by clients and NTP responses sent by NTP servers. If an
	implementation employs the NTP well-known port for the client port	implementation employs the NTP well-known port for the client port, requests/
	number, requests/responses cannot be readily differentiated by	responses cannot be readily differentiated by
	inspecting the source and destination port numbers. Implementation	inspecting the source and destination port numbers.
	of port randomization for non-symmetrical 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.</t>

	</section>


	<section title="Effect on NAPT devices" anchor="sect-3.4"><t>	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 randomizati
		on.</t>
		</section>
		<section anchor="sect-3.4" numbered="true" toc="default">
		<name>Effect on NAPT Devices</name>
		<t>
	Some NAPT devices will reportedly not translate the source port of a	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	packet when a system port number (i.e., a port number in the range

	0-1023) <xref target="RFC6335"/> is employed. In networks where such NAPT de vices	0-1023) <xref target="RFC6335" format="default"/> is employed. In networks w here such NAPT devices
	are employed, use of the NTP well-known port for the client port may	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	limit the number of hosts that may successfully employ NTP client

	implementations at any given time.</t>	implementations at any given time.</t>

	<t>NOTES:
	<list>
	<t> NAPT devices are defined in Section 4.1.2 of <xref target="RFC2663"/>
	.</t>

	<t>The reported behavior is similar to the special treatment of UDP
	port 500 that has been documented in Section 2.3 of <xref target="RFC3715"
	/>.</t>
	</list>
	</t>


	<t>	<aside>
		<t>NOTES:</t>
		<t indent="3">NAPT devices are defined in <xref target="RFC2663" section
		Format="of" section="4.1.2"/>.</t>
		<t indent="3">The reported behavior is similar to the special treatment
		of UDP
		port 500, which has been documented in <xref target="RFC3715" sectionForma
		t="of" section="2.3"/>.</t>
		</aside>
		<t>
	In the case of NAPT devices that will translate the source port even	In the case of NAPT devices that will translate the source port even
	when a system port is employed, packets reaching the external realm	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	of the NAPT will not employ the NTP well-known port as the source

	port, as a result of the port translation function performed by the	port, as a result of the port translation function being performed by the
	NAPT device.</t>	NAPT device.</t>

		</section>
	</section>	</section>
		<section anchor="sect-4" numbered="true" toc="default">
	</section>	<name>Update to RFC 5905</name>
		<t>
	<section title="Update to RFC5905" anchor="sect-4"><t>	The following text from Section
	The following text from Section 9.1 ("Peer Process Variables") of	<xref target="RFC5905" section="9.1" sectionFormat="bare">Peer
	<xref target="RFC5905"/>:</t>	Process Variables</xref> of <xref target="RFC5905"/>:</t>
		<blockquote>
	<t><list style="hanging" hangIndent="3">	<dl newline="false" spacing="normal" indent="3">
	<t hangText="dstport:"> UDP port number of the client, ordinarily the NTP	<dt>dstport:</dt>
	port	<dd> UDP port number of the client, ordinarily the NTP port
	number PORT (123) assigned by the IANA. This becomes the source	number PORT (123) assigned by the IANA. This becomes the source

	port number in packets sent from this association.</t>	port number in packets sent from this association.</dd>
		</dl>
	</list>	</blockquote>
	</t>	<t>is replaced with:</t>

	<t>is replaced with:</t>


	<t><list style="hanging" hangIndent="3">	<blockquote>
	<t hangText="dstport:"> UDP port number of the client. In the case of br	<dl newline="false" spacing="normal" indent="3">
	oadcast	<dt>dstport:</dt>
	server mode (5) and symmetric modes (1 and 2), it SHOULD contain	<dd> UDP port number of the client. In the case of broadcast
	the NTP port number PORT (123) assigned by the IANA. In the	server mode (5) and symmetric modes (1 and 2), it <bcp14>SHOULD</bcp14> co
	client mode (3), it SHOULD contain a randomized port number, as	ntain
	specified in <xref target="RFC6056"/>. The value in this variable becomes	the NTP port number PORT (123) assigned by IANA. In the
	the	client mode (3), it <bcp14>SHOULD</bcp14> contain a randomized port number
		, as
		specified in <xref target="RFC6056" format="default"/>. The value in this
		variable becomes the
	source port number of packets sent from this association. The	source port number of packets sent from this association. The

	randomized port number SHOULD NOT be shared with other	randomized port number <bcp14>SHOULD NOT</bcp14> be shared with other
	associations, to avoid revealing the randomized port to other	associations, to avoid revealing the randomized port to other

	associations.</t>	associations.</dd>
		<dt/>
	<t>If a client implementation performs ephemeral port randomization	<dd>If a client implementation performs transport-protocol ephemeral por
	on a per-request basis, it SHOULD close the corresponding socket/	t randomization
	port after each request/response exchange. In order to prevent	on a per-request basis, it <bcp14>SHOULD</bcp14> close the corresponding
	duplicate or delayed server packets from eliciting ICMP port	socket/port
	unreachable error messages at the client, the client MAY wait for	after each request/response exchange. In order to prevent duplicate
	more responses from the server for a specific period of time (e.g.	or delayed server packets from eliciting ICMP port unreachable error
	3 seconds) before closing the UDP socket/port.</t>	messages <xref target="RFC0792"/> <xref target="RFC4443"/> at the client
		, the client <bcp14>MAY</bcp14> wait for more responses from
	</list>	the server for a specific period of time (e.g., 3 seconds) before
	</t>	closing the UDP socket/port.</dd>
		<dt/>
	<t>NOTES:</t>	<dd/>
		</dl>
	<t>Randomizing the ephemeral port number on a per-request basis	<dl newline="false" spacing="normal" indent="6">
	will better mitigate off-path/blind attacks, particularly if	<dt/><dd><t>NOTES:</t>
		<t>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,	the socket/port is closed after each request/response exchange,
	as recommended above. The choice of whether to randomize the	as recommended above. The choice of whether to randomize the
	ephemeral port number on a per-request or a per-association	ephemeral port number on a per-request or a per-association

	basis is left to the implementation, and should consider the	basis is left to the implementation, and it should consider the
	possible effects on path selection along with its possible	possible effects on path selection along with its possible

	impact on time measurement.</t>	impact on time measurement.</t></dd>
		<dt/>
	<t>On most current operating systems, which implement ephemeral	<dd>On most current operating systems, which implement ephemeral
	port randomization <xref target="RFC6056"/>, an NTP client may normally	port randomization <xref target="RFC6056" format="default"/>, an NTP cl
	rely	ient may normally rely
	on the operating system to perform ephemeral port	on the operating system to perform ephemeral port
	randomization. For example, NTP implementations using POSIX	randomization. For example, NTP implementations using POSIX

	sockets may achieve ephemeral port randomization by not	sockets may achieve ephemeral port randomization by <em>not</em>
	binding the socket with the bind() function, or binding it to	binding the socket with the bind() function or binding it to
	port 0, which has a special meaning of "any port". connect()ing	port 0, which has a special meaning of "any port". Using the connect()
	the socket will make the port inaccessible by other systems	function for the socket will make the port inaccessible
	(that is, only packets from the specified remote socket will be	by other systems (that is, only packets from the specified remote socket will
	received by the application).</t>	be
		received by the application).</dd>
	</section>	</dl>
		</blockquote>
	<section title="Implementation Status" anchor="sect-5"><t>
	[RFC Editor: Please remove this section before publication of this document a
	s an RFC.]</t>

	<t>
	This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in <xref target="RFC7942
	"/>.
	The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by 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, an
	d 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>	</section>
		<section anchor="sect-6" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>
		This document has no IANA actions.</t>
		</section>
		<section anchor="sect-7" numbered="true" toc="default">
		<name>Security Considerations</name>
		<t>
	The security implications of predictable numeric identifiers	The security implications of predictable numeric identifiers

	<xref target="I-D.irtf-pearg-numeric-ids-generation"/> (and of predictable	<xref target="I-D.irtf-pearg-numeric-ids-generation" format="default"/> (and
	transport-protocol port numbers <xref target="RFC6056"/> in particular) have	of predictable
	been	transport-protocol port numbers <xref target="RFC6056" format="default"/> in
		particular) have been
	known for a long time now. However, the NTP specification has	known for a long time now. However, the NTP specification has
	traditionally followed a pattern of employing common settings even	traditionally followed a pattern of employing common settings even
	when not strictly necessary, which at times has resulted in negative	when not strictly necessary, which at times has resulted in negative

	security and privacy implications (see e.g.	security and privacy implications (see, e.g.,
	<xref target="I-D.ietf-ntp-data-minimization"/>). The use of the NTP well-kn	<xref target="I-D.ietf-ntp-data-minimization" format="default"/>). The use o
	own	f the NTP well-known
	port (123) for the srcport and dstport variables is not required for	port (123) for the srcport and dstport variables is not required for
	all operating modes. Such unnecessary usage comes at the expense of	all operating modes. Such unnecessary usage comes at the expense of
	reducing the amount of work required for an attacker to successfully	reducing the amount of work required for an attacker to successfully

	perform off-path/blind attacks against NTP. Therefore, this document	perform blind/off-path attacks against NTP. Therefore, this document
	formally updates <xref target="RFC5905"/>, recommending the use of transport-	formally updates <xref target="RFC5905" format="default"/>, recommending the
	protocol port randomization when use of the NTP well-known port is	use of transport-protocol port randomization when use of the NTP well-known port
		is
	not required.</t>	not required.</t>

		<t>
	<t>	This issue has been assigned CVE-2019-11331 <xref target="VULN-REPORT" format
	This issue has been assigned CVE-2019-11331 <xref target="VULN-REPORT"/> in t	="default"/> in the U.S.
	he U.S.
	National Vulnerability Database (NVD).</t>	National Vulnerability Database (NVD).</t>

		</section>
		</middle>
		<back>


	</section>	<displayreference target="I-D.ietf-ntp-data-minimization" to="NTP-DATA-MINIMIZAT
		ION"/>
	<section title="Acknowledgments" anchor="sect-8"><t>	<displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="PEARG-NUMER
	The authors would like to thank (in alphabetical order) Ivan Arce,	IC-IDS"/>
	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;
	</references>
	<references title="Informative References">
	<reference anchor="chrony" target="https://chrony.tuxfamily.org/"><front>
	<title>chrony</title>
	<author>
	</author>


	<date/>	<references>
	</front>	<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5905.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6056.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>


	</reference>	</references>
	&I-D.ietf-ntp-data-minimization;	<references>
	&I-D.irtf-pearg-numeric-ids-generation;	<name>Informative References</name>
	<reference anchor="NIST-NTP" 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. Sherman">
	</author>


	<author initials="J." surname="Levine" fullname="J. Levine">	<reference anchor='I-D.ietf-ntp-data-minimization'>
	</author>	<front>
		<title>NTP Client Data Minimization</title>
		<author initials='D' surname='Franke' fullname='Daniel Franke'>
		<organization />
		</author>
		<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-minimiza
		tion-04.txt' />
		</reference>


	<date month="March" year="2016"/>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	</front>	.irtf-pearg-numeric-ids-generation.xml"/>


	<seriesInfo name="Journal" value="of Research of the National Institute o	<reference anchor="NIST-NTP" target="https://tf.nist.gov/general/pdf/281
	f Standards and Technology Volume 121"/>	8.pdf">
	</reference>	<front>
	<reference anchor="NTP-CHLNG" target="http://leapsecond.com/ntp/NTP_Paper	<title>Usage Analysis of the NIST Internet Time Service</title>
	_Sommars_PTTI2017.pdf"><front>	<author initials="J." surname="Sherman" fullname="Jeffrey Sherman">
	<title>Challenges in Time Transfer Using the Network Time Protocol (NTP)<
	/title>
	<author initials="S." surname="Sommars" fullname="S. Sommars">
	</author>	</author>

		<author initials="J." surname="Levine" fullname="Judah Levine">
	<date month="January" year="2017"/>
	</front>

	<seriesInfo name="Proceedings" value="of the 48th Annual Precise Time and
	Time Interval Systems and Applications Meeting"/>
	</reference>
	<reference anchor="NTP-FRAG" 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. Malhotra">
	</author>	</author>

		<date month="March" year="2016"/>
		</front>
		<seriesInfo name="DOI" value="10.6028/jres.121.003"/>
		<refcontent>Journal of Research of the National Institute of Standards
		and Technology, Volume 121</refcontent>
		</reference>


	<author initials="I." surname="Cohen" fullname="I. Cohen">	<reference anchor="NTP-CHLNG" target="http://leapsecond.com/ntp/NTP_Pape
		r_Sommars_PTTI2017.pdf">
		<front>
		<title>Challenges in Time Transfer using the Network Time Protocol (
		NTP)</title>
		<author initials="S." surname="Sommars" fullname="Steven Sommars">
	</author>	</author>

		<date month="January" year="2017"/>
		</front>
		<seriesInfo name="DOI" value="10.33012/2017.14978"/>
		<refcontent>Proceedings of the 48th Annual Precise Time and Time Inter
		val Systems and Applications Meeting, pp. 271-290</refcontent>
		</reference>


	<author initials="E." surname="Brakke" fullname="E. Brakke">	<reference anchor="NTP-FRAG" target="https://www.cs.bu.edu/~goldbe/paper
		s/NTPattack.pdf">
		<front>
		<title>Attacking the Network Time Protocol</title>
		<author initials="A." surname="Malhotra" fullname="Aanchal Malhotra"
		>
	</author>	</author>

		<author initials="I." surname="Cohen" fullname="Isaac Cohen">
	<author initials="S." surname="Goldberg" fullname="S. Goldberg">
	</author>	</author>

		<author initials="E." surname="Brakke" fullname="Erik Brakke">
	<date month="Feb" year="2017"/>
	</front>

	</reference>
	<reference anchor="NTP-security" target="https://eprint.iacr.org/2016/100
	6"><front>
	<title>The Security of NTP's Datagram Protocol</title>
	<author initials="A." surname="Malhotra" fullname="A. Malhotra">
	</author>	</author>

		<author initials="S." surname="Goldberg" fullname="Sharon Goldberg">
	<author initials="M." surname="Van Gundy" fullname="M. Van Gundy">
	</author>	</author>

		<date month="February" year="2016"/>
		</front>
		<seriesInfo name="DOI" value="10.14722/ndss.2016.23090"/>
		<refcontent>NDSS '16</refcontent>
		</reference>


	<author initials="V." surname="Varia" fullname="V. Varia">	<reference anchor="NTP-security" target="https://eprint.iacr.org/2016/10
		06.pdf">
		<front>
		<title>The Security of NTP's Datagram Protocol</title>
		<author initials="A." surname="Malhotra" fullname="Aanchal Malhotra"
		>
	</author>	</author>

		<author initials="M." surname="Van Gundy" fullname="Matthew Van Gund
	<author initials="H." surname="Kennedy" fullname="H. Kennedy">	y">
	</author>	</author>

		<author initials="M." surname="Varia" fullname="Mayank Varia">
	<author initials="J." surname="Gardner" fullname="J. Gardner">
	</author>	</author>

		<author initials="H." surname="Kennedy" fullname="Haydn Kennedy">
	<author initials="S." surname="Goldberg" fullname="S. Goldberg">
	</author>	</author>

		<author initials="J." surname="Gardner" fullname="Jonathan Gardner">
	<date year="2016"/>
	</front>

	<seriesInfo name="Cryptology" value="ePrint Archive Report 2016/1006"/>
	</reference>
	<reference anchor="NTP-VULN" target="https://support.ntp.org/bin/view/Mai
	n/SecurityNotice"><front>
	<title>Network Time Foundation</title>
	<author>
	</author>	</author>

		<author initials="S." surname="Goldberg" fullname="Sharon Goldberg">
	<date/>
	</front>

	</reference>
	<reference anchor="OpenNTPD" target="https://www.openntpd.org"><front>
	<title>OpenNTPD Project</title>
	<author>
	</author>	</author>

		<date year="2017" month="February"/>
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-319-70972-7_23"/>
		<refcontent>Cryptology ePrint Archive Report 2016/1006</refcontent>
		</reference>


	<date/>	<reference anchor="NTP-VULN" target="http://support.ntp.org/bin/view/Mai
	</front>	n/SecurityNotice">
		<front>
	</reference>	<title>Network Time Foundation</title>
	&RFC2663;	<author>
	&RFC3715;
	&RFC4953;
	&RFC5927;
	&RFC6335;
	&RFC7942;
	<reference anchor="VULN-REPORT" target="https://cve.mitre.org/cgi-bin/cve
	name.cgi?name=CVE-2019-11331"><front>
	<title>CVE-2019-11331</title>
	<author>
	<organization>The MITRE Corporation</organization>
	</author>	</author>

		<date/>
		</front>
		</reference>


	<date month="April" year="2019"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</front>	FC.2663.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>	FC.3715.xml"/>
	</references>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</back>	FC.4953.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5927.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6335.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.0792.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4443.xml"/>
		<reference anchor="VULN-REPORT" target="https://cve.mitre.org/cgi-bin/cv
		ename.cgi?name=CVE-2019-11331">
		<front>
		<title>CVE-2019-1133</title>
		<author>
		<organization>The MITRE Corporation</organization>
		</author>
		<date month="August" year="2020"/>
		</front>
		<refcontent>National Vulnerability Database</refcontent>
		</reference>


	</rfc>	</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="Iv
		an Arce"/>,
		<contact fullname="Roman Danyliw"/>, <contact fullname="Dhruv Dhody"/>, <cont
		act fullname="Lars Eggert"/>, <contact fullname="Todd Glassey"/>, <contact fulln
		ame="Blake Hudson"/>,
		<contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <cont
		act fullname="Watson Ladd"/>, <contact fullname="Aanchal Malhotra"/>, <contact f
		ullname="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"/>, <conta
		ct 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"/> o
		f this document).</t>
		<t>
		The authors would like to thank <contact fullname="Harlan Stenn"/> for answer
		ing 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="Ne
		lida Garcia"/> and <contact fullname="Jorge Oscar Gont"/> for
		their love and support.</t>
		</section>
		</back>
		</rfc>

End of changes. 74 change blocks.
	479 lines changed or deleted	397 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/