< draft-ietf-ntp-mode-6-cmds-05.txt		draft-ietf-ntp-mode-6-cmds-06.txt >
	Network Working Group D. Mills		Network Working Group B. Haberman, Ed.
	Internet-Draft University of Delaware		Internet-Draft JHU
	Intended status: Informational B. Haberman, Ed.		Intended status: Informational September 27, 2018
	Expires: September 27, 2018 JHU		Expires: March 31, 2019
	March 26, 2018
	Control Messages Protocol for Use with Network Time Protocol Version 4		Control Messages Protocol for Use with Network Time Protocol Version 4
	draft-ietf-ntp-mode-6-cmds-05		draft-ietf-ntp-mode-6-cmds-06
	Abstract		Abstract
	This document describes the structure of the control messages used		This document describes the structure of the control messages that
	with the Network Time Protocol. These control messages can be used		were historically used with the Network Time Protocol before the
	to monitor and control the Network Time Protocol application running		advent of more modern control and management approaches. These
	on any IP network attached computer. The information in this		control messages have been used to monitor and control the Network
	document was originally described in Appendix B of RFC 1305. The		Time Protocol application running on any IP network attached
	goal of this document is to provide a historic description of the		computer. The information in this document was originally described
	control messages as described in RFC 1305 and any additional commands		in Appendix B of RFC 1305. The goal of this document is to provide a
	implemented in NTP.		current, but historic, description of the control messages as
			described in RFC 1305 and any additional commands implemented in NTP.
			The publication of this document is not meant to encourage the
			developement and deployment of these control messages. This document
			is only providing a current reference for these control messages
			given the current status of RFC 1305.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 27, 2018.		This Internet-Draft will expire on March 31, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 29 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Control Message Overview . . . . . . . . . . . . . . . . 3		1.1. Control Message Overview . . . . . . . . . . . . . . . . 3
	1.2. Remote Facility Message Overview . . . . . . . . . . . . 4		1.2. Remote Facility Message Overview . . . . . . . . . . . . 4
	2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4		2. NTP Control Message Format . . . . . . . . . . . . . . . . . 5
	3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8		3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8
	3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10		3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10
	3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12		3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12
	3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12		3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12
	4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	8. Normative References . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. NTP Remote Facility Message Format . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 18
			9.2. Informative References . . . . . . . . . . . . . . . . . 19
			Appendix A. NTP Remote Facility Message Format . . . . . . . . . 19
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	RFC 1305 [RFC1305] described a set of control messages for use within		RFC 1305 [RFC1305] described a set of control messages for use within
	the Network Time Protocol (NTP) when a comprehensive network		the Network Time Protocol (NTP) when a comprehensive network
	management solution was not available. The definitions of these		management solution was not available. The definitions of these
	control messages were not promulgated to RFC 5905 [RFC5905] when NTP		control messages were not promulgated to RFC 5905 [RFC5905] when NTP
	version 4 was documented. These messages were intended for use only		version 4 was documented. These messages were intended for use only
	in systems where no other management facilities were available or		in systems where no other management facilities were available or
	appropriate, such as in dedicated-function bus peripherals. Support		appropriate, such as in dedicated-function bus peripherals. Support
	for these messages is not required in order to conform to RFC 5905		for these messages is not required in order to conform to RFC 5905
	[RFC5905]. The control messages are described here as a historical		[RFC5905]. The control messages are described here as a historical
	record given their use within NTPv4.		record given their use within NTPv4.
			The publication of this document is not meant to encourage the
			developement and deployment of these control messages. This document
			is only providing a current reference for these control messages
			given the current status of RFC 1305.
	1.1. Control Message Overview		1.1. Control Message Overview
	The NTP Control Message has the value 6 specified in the mode field		The NTP Control Message has the value 6 specified in the mode field
	of the first octet of the NTP header and is formatted as shown in		of the first octet of the NTP header and is formatted as shown in
	Figure 1. The format of the data field is specific to each command		Figure 1. The format of the data field is specific to each command
	or response; however, in most cases the format is designed to be		or response; however, in most cases the format is designed to be
	constructed and viewed by humans and so is coded in free-form ASCII.		constructed and viewed by humans and so is coded in free-form ASCII.
	This facilitates the specification and implementation of simple		This facilitates the specification and implementation of simple
	management tools in the absence of fully evolved network-management		management tools in the absence of fully evolved network-management
	facilities. As in ordinary NTP messages, the authenticator field		facilities. As in ordinary NTP messages, the authenticator field
	follows the data field. If the authenticator is used the data field		follows the data field. If the authenticator is used the data field
	is zero-padded to a 32-bit boundary, but the padding bits are not		is zero-padded to a 32-bit boundary, but the padding bits are not
	considered part of the data field and are not included in the field		considered part of the data field and are not included in the field
	count.		count.
	IP hosts are not required to reassemble datagrams larger than 576		IP hosts are not required to reassemble datagrams larger than 576
	octets; however, some commands or responses may involve more data		octets [RFC0791]; however, some commands or responses may involve
	than will fit into a single datagram. Accordingly, a simple		more data than will fit into a single datagram. Accordingly, a
	reassembly feature is included in which each octet of the message		simple reassembly feature is included in which each octet of the
	data is numbered starting with zero. As each fragment is transmitted		message data is numbered starting with zero. As each fragment is
	the number of its first octet is inserted in the offset field and the		transmitted the number of its first octet is inserted in the offset
	number of octets is inserted in the count field. The more-data (M)		field and the number of octets is inserted in the count field. The
	bit is set in all fragments except the last.		more-data (M) bit is set in all fragments except the last.
	Most control functions involve sending a command and receiving a		Most control functions involve sending a command and receiving a
	response, perhaps involving several fragments. The sender chooses a		response, perhaps involving several fragments. The sender chooses a
	distinct, nonzero sequence number and sets the status field and R and		distinct, nonzero sequence number and sets the status field and "R"
	E bits to zero. The responder interprets the opcode and additional		and "E" bits to zero. The responder interprets the opcode and
	information in the data field, updates the status field, sets the R		additional information in the data field, updates the status field,
	bit to one and returns the three 32-bit words of the header along		sets the "R" bit to one and returns the three 32-bit words of the
	with additional information in the data field. In case of invalid		header along with additional information in the data field. In case
	message format or contents the responder inserts a code in the status		of invalid message format or contents the responder inserts a code in
	field, sets the R and E bits to one and, optionally, inserts a		the status field, sets the "R" and "E" bits to one and, optionally,
	diagnostic message in the data field.		inserts a diagnostic message in the data field.
	Some commands read or write system variables and peer variables for		Some commands read or write system variables (e.g., s.offset) and
	an association identified in the command. Others read or write		peer variables (e.g., p.stratum) for an association identified in the
	variables associated with a radio clock or other device directly		command. Others read or write variables associated with a radio
	connected to a source of primary synchronization information. To		clock or other device directly connected to a source of primary
	identify which type of variable and association a 16-bit association		synchronization information. To identify which type of variable and
	identifier is used. System variables are indicated by the identifier		association the Association ID is used. System variables are
	zero. As each association is mobilized a unique, nonzero identifier		indicated by the identifier zero. As each association is mobilized a
	is created for it. These identifiers are used in a cyclic fashion,		unique, nonzero identifier is created for it. These identifiers are
	so that the chance of using an old identifier which matches a newly		used in a cyclic fashion, so that the chance of using an old
	created association is remote. A management entity can request a		identifier which matches a newly created association is remote. A
	list of current identifiers and subsequently use them to read and		management entity can request a list of current identifiers and
	write variables for each association. An attempt to use an expired		subsequently use them to read and write variables for each
	identifier results in an exception response, following which the list		association. An attempt to use an expired identifier results in an
	can be requested again.		exception response, following which the list can be requested again.
	Some exception events, such as when a peer becomes reachable or		Some exception events, such as when a peer becomes reachable or
	unreachable, occur spontaneously and are not necessarily associated		unreachable, occur spontaneously and are not necessarily associated
	with a command. An implementation may elect to save the event		with a command. An implementation may elect to save the event
	information for later retrieval or to send an asynchronous response		information for later retrieval or to send an asynchronous response
	(called a trap) or both. In case of a trap the IP address and port		(called a trap) or both. In case of a trap the IP address and port
	number is determined by a previous command and the sequence field is		number is determined by a previous command and the sequence field is
	set as described below. Current status and summary information for		set as described below. Current status and summary information for
	the latest exception event is returned in all normal responses. Bits		the latest exception event is returned in all normal responses. Bits
	in the status field indicate whether an exception has occurred since		in the status field indicate whether an exception has occurred since
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 32 ¶
	Figure 2. When present, the data field contains a list of		Figure 2. When present, the data field contains a list of
	identifiers or assignments in the form		identifiers or assignments in the form
	<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where		<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where
	<<identifier>> is the ASCII name of a system or peer variable		<<identifier>> is the ASCII name of a system or peer variable
	specified in RFC 5905 and <<value>> is expressed as a decimal,		specified in RFC 5905 and <<value>> is expressed as a decimal,
	hexadecimal or string constant in the syntax of the C programming		hexadecimal or string constant in the syntax of the C programming
	language. Where no ambiguity exists, the <169>sys.<170> or		language. Where no ambiguity exists, the <169>sys.<170> or
	<169>peer.<170> prefixes can be suppressed. Whitespace (ASCII		<169>peer.<170> prefixes can be suppressed. Whitespace (ASCII
	nonprinting format effectors) can be added to improve readability for		nonprinting format effectors) can be added to improve readability for
	simple monitoring programs that do not reformat the data field.		simple monitoring programs that do not reformat the data field.
	Internet addresses are represented as four octets in the form		Internet addresses are represented as follows: IPv4 addresses are
	[n.n.n.n], where n is in decimal notation and the brackets are		written in the form [n.n.n.n], where n is in decimal notation and the
	optional. Timestamps, including reference, originate, receive and		brackets are optional; IPv6 addresses are formulated based on the
	transmit values, as well as the logical clock, are represented in		guidelines defined in [RFC5952]. Timestamps, including reference,
	units of seconds and fractions, preferably in hexadecimal notation,		originate, receive and transmit values, as well as the logical clock,
	while delay, offset, dispersion and distance values are represented		are represented in units of seconds and fractions, preferably in
	in units of milliseconds and fractions, preferably in decimal		hexadecimal notation. Delay, offset, dispersion and distance values
	notation. All other values are represented as-is, preferably in		are represented in units of milliseconds and fractions, preferably in
	decimal notation.		decimal notation. All other values are represented as-is, preferably
			in decimal notation.
	Implementations may define variables other than those described in		Implementations may define variables other than those described in
	RFC 5905. Called extramural variables, these are distinguished by		RFC 5905. Called extramural variables, these are distinguished by
	the inclusion of some character type other than alphanumeric or		the inclusion of some character type other than alphanumeric or
	<169>.<170> in the name. For those commands that return a list of		<169>.<170> in the name. For those commands that return a list of
	assignments in the response data field, if the command data field is		assignments in the response data field, if the command data field is
	empty, it is expected that all available variables defined in RFC		empty, it is expected that all available variables defined in RFC
	5905 will be included in the response. For the read commands, if the		5905 will be included in the response. For the read commands, if the
	command data field is nonempty, an implementation may choose to		command data field is nonempty, an implementation may choose to
	process this field to individually select which variables are to be		process this field to individually select which variables are to be
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 11 ¶
	part of the variable name preceding the equals sign and value, where		part of the variable name preceding the equals sign and value, where
	each index relates information for a single address or network. This		each index relates information for a single address or network. This
	opcode requires authentication.		opcode requires authentication.
	Request Nonce (12): Retrieves a 96-bit nonce specific to the		Request Nonce (12): Retrieves a 96-bit nonce specific to the
	requesting remote address, which is valid for a limited period.		requesting remote address, which is valid for a limited period.
	Command data is not used in the request. The nonce consists of a		Command data is not used in the request. The nonce consists of a
	64-bit NTP timestamp and 32 bits of hash derived from that timestamp,		64-bit NTP timestamp and 32 bits of hash derived from that timestamp,
	the remote address, and salt known only to the server which varies		the remote address, and salt known only to the server which varies
	between daemon runs. The reference implementation honors nonces		between daemon runs. The reference implementation honors nonces
	which were issued less than 16 seconds prior. Regurgitation of the		which were issued less than 16 seconds prior. Inclusion of the nonce
	nonce by a managment agent demonstrates to the server that the agent		by a managment agent demonstrates to the server that the agent can
	can receive datagrams sent to the source address of the request,		receive datagrams sent to the source address of the request, making
	making source address "spoofing" more difficult in a similar way as		source address "spoofing" more difficult in a similar way as TCP's
	TCP's three-way handshake.		three-way handshake.
	Unset Trap (31): Removes the requesting remote address and port from		Unset Trap (31): Removes the requesting remote address and port from
	the list of trap receivers. Command data is not used in the request.		the list of trap receivers. Command data is not used in the request.
	If the address and port are not in the list of trap receivers, the		If the address and port are not in the list of trap receivers, the
	error code is 4, bad association.		error code is 4, bad association.
	5. IANA Considerations		5. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	skipping to change at page 16, line 52 ¶		skipping to change at page 16, line 52 ¶
	access controls are required for the following reasons:		access controls are required for the following reasons:
	o NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing		o NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing
	query and response packets (modes 1-2, 3-4, 5) are usually short		query and response packets (modes 1-2, 3-4, 5) are usually short
	in size. However, some NTP control queries generate a very long		in size. However, some NTP control queries generate a very long
	packet in response to a short query. As such, there is a history		packet in response to a short query. As such, there is a history
	of use of NTP's control queries, which exhibit such behavior, to		of use of NTP's control queries, which exhibit such behavior, to
	perform DDoS attacks. These off-path attacks exploit the large		perform DDoS attacks. These off-path attacks exploit the large
	size of NTP control queries to cause UDP-based amplification		size of NTP control queries to cause UDP-based amplification
	attacks (e.g., mode 7 monlist command generates a very long packet		attacks (e.g., mode 7 monlist command generates a very long packet
	in response to a small query (CVE-2013-5211)). These attacks only		in response to a small query [CVE-DOS]). These attacks only use
	use NTP as a vector for DoS atacks on other protocols, but do not		NTP as a vector for DoS atacks on other protocols, but do not
	affect the time service on the NTP host itself. To limit the		affect the time service on the NTP host itself. To limit the
	sources of these malicious commands, NTP server operators are		sources of these malicious commands, NTP server operators are
	recommended to deploy ingress filtering [RFC2827].		recommended to deploy ingress filtering [RFC2827].
	o Time-shifting attacks through information leakage/overwriting.		o Time-shifting attacks through information leakage/overwriting.
	NTP hosts save important system and peer state variables. An off-		NTP hosts save important system and peer state variables. An off-
	path attacker who can read these variables remotely can leverage		path attacker who can read these variables remotely can leverage
	the information leaked by these control queries to perform time-		the information leaked by these control queries to perform time-
	shifting and DoS attacks on NTP clients. These attacks do affect		shifting and DoS attacks on NTP clients. These attacks do affect
	time synchronization on the NTP hosts. For instance,		time synchronization on the NTP hosts. For instance,
	* In the client/server mode, the client stores its local time		* In the client/server mode, the client stores its local time
	when it sends the query to the server in its xmt peer variable.		when it sends the query to the server in its xmt peer variable.
	This variable is used to perform TEST2 to non-cryptographically		This variable is used to perform TEST2 to non-cryptographically
	authenticate the server, i.e., if the origin timestamp field in		authenticate the server, i.e., if the origin timestamp field in
	the corresponding server response packet matches the xmt peer		the corresponding server response packet matches the xmt peer
	variable, then the client accepts the packet. An off-path		variable, then the client accepts the packet. An off-path
	attacker, with the ability to read this variable can easily		attacker, with the ability to read this variable can easily
	spoof server response packets for the client, which will pass		spoof server response packets for the client, which will pass
	TEST2, and can deny service or shift time on the NTP client.		TEST2, and can deny service or shift time on the NTP client.
	CVE-2015-8139 describes the specific attack.		The specific attack is described in [CVE-SPOOF].
	* The client also stores its local time when the server response		* The client also stores its local time when the server response
	is received in its rec peer variable. This variable is used		is received in its rec peer variable. This variable is used
	for authentication in interleaved-pivot mode. An off-path		for authentication in interleaved-pivot mode. An off-path
	attacker with the ability to read this state variable can		attacker with the ability to read this state variable can
	easily shift time on the client by passing this test. CVE-		easily shift time on the client by passing this test. This
	2016-1548 describes the attack.		attack is described in [CVE-SHIFT].
	o Fast-Scanning. NTP mode 6 control messages are usually small UDP		o Fast-Scanning. NTP mode 6 control messages are usually small UDP
	packets. Fast-scanning tools like ZMap can be used to spray the		packets. Fast-scanning tools like ZMap can be used to spray the
	entire (potentially reachable) Internet with these messages within		entire (potentially reachable) Internet with these messages within
	hours to identify vulnerable hosts. To make things worse, these		hours to identify vulnerable hosts. To make things worse, these
	attacks can be extremely low-rate, only requiring a control query		attacks can be extremely low-rate, only requiring a control query
	for reconnaissance and a spoofed response to shift time on		for reconnaissance and a spoofed response to shift time on
	vulnerable clients. CVE-2016-1548 is one such example.		vulnerable clients.
			o The mode 6 and 7 messages are vulnerable to replay attacks
			[CVE-Replay]. If an attacker observes mode 6/7 packets that
			modify the configuration of the server in any way, the attacker
			can apply the same change at any time later simply by sending the
			packets to the server again.
	NTP best practices recommend configuring ntpd with the no-query		NTP best practices recommend configuring ntpd with the no-query
	parameter. The no-query parameter blocks access to all remote		parameter. The no-query parameter blocks access to all remote
	control queries. However, sometimes the nosts do not want to block		control queries. However, sometimes the hosts do not want to block
	all queries and want to give access for certain control queries		all queries and want to give access for certain control queries
	remotely. This could be for the purpose of remote management and		remotely. This could be for the purpose of remote management and
	configuration of the hosts in certain scenarios. Such hosts tend to		configuration of the hosts in certain scenarios. Such hosts tend to
	use firewalls or other middleboxes to blacklist certain queries		use firewalls or other middleboxes to blacklist certain queries
	within the network.		within the network.
	Recent work (reference needed) shows that significantly fewer hosts		Significantly fewer hosts respond to mode 7 monlist queries as
	respond to mode 7 monlist queries as compared to other control		compared to other control queries because it is a well-known and
	queries because it is a well-known and exploited control query.		exploited control query. These queries are likely blocked using
	These queries are likely blocked using blacklists on firewalls and		blacklists on firewalls and middleboxes rather than the no-query
	middleboxes rather than the no-query option on NTP hosts. The		option on NTP hosts. The remaining control queries that can be
	remaining control queries that can be exploited likely remain out of		exploited likely remain out of the blacklist because they are
	the blacklist because they are undocumented in the current NTP		undocumented in the current NTP specification [RFC5905].
	specification [RFC5905].
	This document describes all of the mode 6 control queries allowed by		This document describes all of the mode 6 control queries allowed by
	NTP and can help administrators make informed decisions on security		NTP and can help administrators make informed decisions on security
	measures to protect NTP devices from harmful queries and likely make		measures to protect NTP devices from harmful queries and likely make
	those systems less vulnerable.		those systems less vulnerable. Regardless of which mode 6 commands
			an administrator elect to allow, remote access to this facility needs
			to be protected from unauthorized access (e.g., strict ACLs).
	7. Acknowledgements		7. Contributors
			Dr. David Mills specified the vast majority of the mode 6 commands
			during the development of RFC 1305 [RFC1305] and deserves the credit
			for their existence and use.
			8. Acknowledgements
	Tim Plunkett created the original version of this document. Aanchal		Tim Plunkett created the original version of this document. Aanchal
	Malhotra provided the initial version of the Security Considerations		Malhotra provided the initial version of the Security Considerations
	section.		section.
	Karen O'Donoghue, David Hart, Harlan Stenn, and Philip Chimento		Karen O'Donoghue, David Hart, Harlan Stenn, and Philip Chimento
	deserve credit for portions of this document due to their earlier		deserve credit for portions of this document due to their earlier
	efforts to document these commands.		efforts to document these commands.
	8. Normative References		Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-
			Hamelin, and Alex Campbell provided valuable comments on various
			versions of this document.
			9. References
			9.1. Normative References
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation and Analysis", RFC 1305,		Specification, Implementation and Analysis", RFC 1305,
	DOI 10.17487/RFC1305, March 1992,		DOI 10.17487/RFC1305, March 1992,
	<https://www.rfc-editor.org/info/rfc1305>.		<https://www.rfc-editor.org/info/rfc1305>.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,		Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
	May 2000, <https://www.rfc-editor.org/info/rfc2827>.		May 2000, <https://www.rfc-editor.org/info/rfc2827>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<https://www.rfc-editor.org/info/rfc5905>.
			[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
			Address Text Representation", RFC 5952,
			DOI 10.17487/RFC5952, August 2010,
			<https://www.rfc-editor.org/info/rfc5952>.
			9.2. Informative References
			[CVE-DOS] NIST National Vulnerability Database, "CVE-2013-5211,
			https://nvd.nist.gov/vuln/detail/CVE-2013-5211", January
			2014.
			[CVE-Replay]
			NIST National Vulnerability Database, "CVE-2015-8140,
			https://nvd.nist.gov/vuln/detail/CVE-2015-8140", January
			2015.
			[CVE-SHIFT]
			NIST National Vulnerability Database, "CVE-2016-1548,
			https://nvd.nist.gov/vuln/detail/CVE-2016-1548", January
			2017.
			[CVE-SPOOF]
			NIST National Vulnerability Database, "CVE-2015-8139,
			https://nvd.nist.gov/vuln/detail/CVE-2015-8139", January
			2017.
			[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
			DOI 10.17487/RFC0791, September 1981,
			<https://www.rfc-editor.org/info/rfc791>.
	Appendix A. NTP Remote Facility Message Format		Appendix A. NTP Remote Facility Message Format
	The format of the NTP Remote Facility Message header, which		The format of the NTP Remote Facility Message header, which
	immediately follows the UDP header, is shown in Figure 3. Following		immediately follows the UDP header, is shown in Figure 3. Following
	is a description of its fields. Bit positions marked as zero are		is a description of its fields. Bit positions marked as zero are
	reserved and should always be transmitted as zero.		reserved and should always be transmitted as zero.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 20, line 44 ¶		skipping to change at page 21, line 44 ¶
	Encryption KeyID : A 32-bit unsigned integer used to designate the		Encryption KeyID : A 32-bit unsigned integer used to designate the
	key used for the Message Authentication Code. This field is included		key used for the Message Authentication Code. This field is included
	only when the A bit is set to 1.		only when the A bit is set to 1.
	Message Authentication Code : An optional Message Authentication Code		Message Authentication Code : An optional Message Authentication Code
	defined by the version of the NTP daemon indicated in the		defined by the version of the NTP daemon indicated in the
	Implementation field. This field is included only when the A bit is		Implementation field. This field is included only when the A bit is
	set to 1.		set to 1.
	Authors' Addresses		Author's Address
	Dr. David L. Mills
	University of Delaware
	Email: mills@udel.edu
	Brian Haberman (editor)		Brian Haberman (editor)
	JHU		JHU
	Email: brian@innovationslab.net		Email: brian@innovationslab.net
End of changes. 25 change blocks.
	87 lines changed or deleted		146 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/