< draft-ietf-ntp-mode-6-cmds-09.txt   draft-ietf-ntp-mode-6-cmds-10.txt >
Network Working Group B. Haberman, Ed. Network Working Group B. Haberman, Ed.
Internet-Draft JHU Internet-Draft JHU
Intended status: Informational June 22, 2020 Intended status: Historic September 28, 2020
Expires: December 24, 2020 Expires: April 1, 2021
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-09 draft-ietf-ntp-mode-6-cmds-10
Abstract Abstract
This document describes the structure of the control messages that This document describes the structure of the control messages that
were historically used with the Network Time Protocol before the were historically used with the Network Time Protocol before the
advent of more modern control and management approaches. These advent of more modern control and management approaches. These
control messages have been used to monitor and control the Network control messages have been used to monitor and control the Network
Time Protocol application running on any IP network attached Time Protocol application running on any IP network attached
computer. The information in this document was originally described computer. The information in this document was originally described
in Appendix B of RFC 1305. The goal of this document is to provide a in Appendix B of RFC 1305. The goal of this document is to provide
current, but historic, description of the control messages as an updated description of the control messages described in RFC 1305
described in RFC 1305 and any additional commands implemented in NTP. in order to conform with the updated Network Time Protocol
specification documented in RFC 5905.
The publication of this document is not meant to encourage the The publication of this document is not meant to encourage the
developement and deployment of these control messages. This document development and deployment of these control messages. This document
is only providing a current reference for these control messages is only providing a current reference for these control messages
given the current status of RFC 1305. 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 December 24, 2020. This Internet-Draft will expire on April 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 15 skipping to change at page 3, line 15
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 current
record given their use within NTPv4. reference for use with an RFC 5905 implementation of NTP.
The publication of this document is not meant to encourage the The publication of this document is not meant to encourage the
developement and deployment of these control messages. This document development and deployment of these control messages. This document
is only providing a current reference for these control messages is only providing a current reference for these control messages
given the current status of RFC 1305. given the current status of RFC 1305.
1.1. Control Message Overview 1.1. Control Message Overview
The NTP Mode 6 control messages are used by NTP management programs The NTP Mode 6 control messages are used by NTP management programs
(e.g., ntpq) when a more robust network management facility (e.g., (e.g., ntpq) when a more robust network management facility (e.g.,
SNMP) is not available. These control messages provide rudimentary SNMP) is not available. These control messages provide rudimentary
control and monitoring functions to manage a running instance of an control and monitoring functions to manage a running instance of an
NTP server. These commands are not designed to be used for NTP server. These commands are not designed to be used for
skipping to change at page 3, line 45 skipping to change at page 3, line 45
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 over a certain size
octets [RFC0791]; however, some commands or responses may involve (576 octets for IPv4 [RFC0791] and 1280 octets for IPv6 [RFC2460]);
more data than will fit into a single datagram. Accordingly, a however, some commands or responses may involve more data than will
simple reassembly feature is included in which each octet of the fit into a single datagram. Accordingly, a simple reassembly feature
message data is numbered starting with zero. As each fragment is is included in which each octet of the message data is numbered
transmitted the number of its first octet is inserted in the offset starting with zero. As each fragment is transmitted the number of
field and the number of octets is inserted in the count field. The its first octet is inserted in the offset field and the number of
more-data (M) bit is set in all fragments except the last. octets is inserted in the count field. The 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" distinct, nonzero sequence number and sets the status field and "R"
and "E" bits to zero. The responder interprets the opcode and and "E" bits to zero. The responder interprets the opcode and
additional information in the data field, updates the status field, additional information in the data field, updates the status field,
sets the "R" bit to one and returns the three 32-bit words of the sets the "R" bit to one and returns the three 32-bit words of the
header along with additional information in the data field. In case header along with additional information in the data field. In case
of invalid message format or contents the responder inserts a code in of invalid message format or contents the responder inserts a code in
the status field, sets the "R" and "E" bits to one and, optionally, the status field, sets the "R" and "E" bits to one and, optionally,
skipping to change at page 4, line 44 skipping to change at page 4, line 46
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
the last response and whether more than one exception has occurred. the last response and whether more than one exception has occurred.
Commands need not necessarily be sent by an NTP peer, so ordinary Commands need not necessarily be sent by an NTP peer, so ordinary
access-control procedures may not apply; however, the optional mask/ access-control procedures may not apply; however, the optional mask/
match mechanism suggested elsewhere in this document provides the match mechanism suggested in Section Section 6 elsewhere in this
capability to control access by mode number, so this could be used to document provides the capability to control access by mode number, so
limit access for control messages (mode 6) to selected address this could be used to limit access for control messages (mode 6) to
ranges. selected address ranges.
1.2. Remote Facility Message Overview 1.2. Remote Facility Message Overview
The original development of the NTP daemon included a remote facility The original development of the NTP daemon included a remote facility
(ntpdc) for monitoring and configuration. This facility used mode 7 for monitoring and configuration. This facility used mode 7 commands
commands to communicate with the NTP daemon. This document to communicate with the NTP daemon. This document illustrates the
illustrates the mode 7 packet format only. The commands embedded in mode 7 packet format only. The commands embedded in the mode 7
the mode 7 messages are implementation specific and not standardized messages are implementation specific and not standardized in any way.
in any way. The mode 7 message format is described in Appendix A. The mode 7 message format is described in Appendix A.
2. NTP Control Message Format 2. NTP Control Message Format
The format of the NTP Control Message header, which immediately The format of the NTP Control Message header, which immediately
follows the UDP header, is shown in Figure 1. Following is a follows the UDP header, is shown in Figure 1. Following is a
description of its fields. Bit positions marked as zero are reserved description of its fields.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode |R|E|M| OpCode | Sequence Number | |LI | VN |Mode |R|E|M| OpCode | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Association ID | | Status | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count | | Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data (up to 468 bytes) / / Data (up to 468 bytes) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) | | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Authenticator (optional, 96 bits) / / Authenticator (optional, 20 or 24 bits) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP Control Message Header Figure 1: NTP Control Message Header
Leap Indicator (LI): This is a two-bit integer that is set to b00 for Leap Indicator (LI): This is a two-bit integer that is set to b00 for
control message requests and responses. The Leap Indicator value control message requests and responses. The Leap Indicator value
used at this position in most NTP modes is in the System Status Word used at this position in most NTP modes is in the System Status Word
provided in some control message responses. provided in some control message responses.
skipping to change at page 7, line 19 skipping to change at page 7, line 16
octets, of the first octet in the data area. The offset is set to octets, of the first octet in the data area. The offset is set to
zero in requests. Responses spanning multiple datagrams use a zero in requests. Responses spanning multiple datagrams use a
positive offset in all but the first datagram. positive offset in all but the first datagram.
Count: This is a 16-bit unsigned integer indicating the length of the Count: This is a 16-bit unsigned integer indicating the length of the
data field, in octets. data field, in octets.
Data: This contains the message data for the command or response. Data: This contains the message data for the command or response.
The maximum number of data octets is 468. The maximum number of data octets is 468.
Padding (optional): Conains zero to three octets with value zero, as Padding (optional): Contains zero to three octets with value zero, as
needed to ensure the overall control message size is a multiple of 4 needed to ensure the overall control message size is a multiple of 4
octets. octets.
Authenticator (optional): When the NTP authentication mechanism is Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information defined in implemented, this contains the authenticator information defined in
Appendix C of RFC 1305. Appendix C of [RFC1305].
3. Status Words 3. Status Words
Status words indicate the present status of the system, associations Status words indicate the present status of the system, associations
and clock. They are designed to be interpreted by network-monitoring and clock. They are designed to be interpreted by network-monitoring
programs and are in one of four 16-bit formats shown in Figure 2 and programs and are in one of four 16-bit formats shown in Figure 2 and
described in this section. System and peer status words are described in this section. System and peer status words are
associated with responses for all commands except the read clock associated with responses for all commands except the read clock
variables, write clock variables and set trap address/port commands. variables, write clock variables and set trap address/port commands.
The association identifier zero specifies the system status word, The association identifier zero specifies the system status word,
skipping to change at page 10, line 41 skipping to change at page 10, line 41
also in the list of association identifiers and status words returned also in the list of association identifiers and status words returned
by a read status command with a zero association identifier. The by a read status command with a zero association identifier. The
format of a peer status word is as follows: format of a peer status word is as follows:
Peer Status (Status): This is a five-bit code indicating the status Peer Status (Status): This is a five-bit code indicating the status
of the peer determined by the packet procedure, with bits assigned as of the peer determined by the packet procedure, with bits assigned as
follows: follows:
+-------------+---------------------------------------------------+ +-------------+---------------------------------------------------+
| Peer Status | Meaning | | Peer Status | Meaning |
| bit | |
+-------------+---------------------------------------------------+ +-------------+---------------------------------------------------+
| 0 | configured (peer.config) | | 0 | configured (peer.config) |
| 1 | authentication enabled (peer.authenable) | | 1 | authentication enabled (peer.authenable) |
| 2 | authentication okay (peer.authentic) | | 2 | authentication okay (peer.authentic) |
| 3 | reachability okay (peer.reach != 0) | | 3 | reachability okay (peer.reach != 0) |
| 4 | broadcast association | | 4 | broadcast association |
+-------------+---------------------------------------------------+ +-------------+---------------------------------------------------+
Peer Selection (SEL): This is a three-bit integer indicating the Peer Selection (SEL): This is a three-bit integer indicating the
status of the peer determined by the clock-selection procedure, with status of the peer determined by the clock-selection procedure, with
skipping to change at page 11, line 38 skipping to change at page 11, line 38
| Peer | | | Peer | |
| Event | Meaning | | Event | Meaning |
| Code | | | Code | |
+-------+--------------------------------------------------------+ +-------+--------------------------------------------------------+
| 0 | unspecified | | 0 | unspecified |
| 1 | association mobilized | | 1 | association mobilized |
| 2 | association demobilized | | 2 | association demobilized |
| 3 | peer unreachable (peer.reach was nonzero now zero) | | 3 | peer unreachable (peer.reach was nonzero now zero) |
| 4 | peer reachable (peer.reach was zero now nonzero) | | 4 | peer reachable (peer.reach was zero now nonzero) |
| 5 | association restarted or timed out | | 5 | association restarted or timed out |
| 6 | no reply (only used with one-shot ntpd -q) | | 6 | no reply (only used with one-shot clock set command) |
| 7 | peer rate limit exceeded (kiss code RATE received) | | 7 | peer rate limit exceeded (kiss code RATE received) |
| 8 | access denied (kiss code DENY received) | | 8 | access denied (kiss code DENY received) |
| 9 | leap second insertion/deletion at month's end armed | | 9 | leap second insertion/deletion at month's end armed |
| | by peer vote | | | by peer vote |
| 10 | became system peer (sys.peer) | | 10 | became system peer (sys.peer) |
| 11 | reference clock event (see clock status word) | | 11 | reference clock event (see clock status word) |
| 12 | authentication failed | | 12 | authentication failed |
| 13 | popcorn spike suppressed by peer clock filter register | | 13 | popcorn spike suppressed by peer clock filter register |
| 14 | entering interleaved mode | | 14 | entering interleaved mode |
| 15 | recovered from interleave error | | 15 | recovered from interleave error |
skipping to change at page 13, line 22 skipping to change at page 13, line 22
| 4 | unknown association identifier | | 4 | unknown association identifier |
| 5 | unknown variable name | | 5 | unknown variable name |
| 6 | invalid variable value | | 6 | invalid variable value |
| 7 | administratively prohibited | | 7 | administratively prohibited |
| 8-255 | reserved | | 8-255 | reserved |
+--------------+--------------------------------------------------+ +--------------+--------------------------------------------------+
4. Commands 4. Commands
Commands consist of the header and optional data field shown in Commands consist of the header and optional data field shown in
Figure 2. When present, the data field contains a list of Figure 1. 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 such as
specified in RFC 5905 and <<value>> is expressed as a decimal, the ones specified in RFC 5905 and <<value>> is expressed as a
hexadecimal or string constant in the syntax of the C programming decimal, hexadecimal or string constant in the syntax of the C
language. Where no ambiguity exists, the <169>sys.<170> or programming language. Where no ambiguity exists, the "sys." or
<169>peer.<170> prefixes can be suppressed. Whitespace (ASCII "peer." prefixes can be suppressed. Whitespace (ASCII nonprinting
nonprinting format effectors) can be added to improve readability for format effectors) can be added to improve readability for simple
simple monitoring programs that do not reformat the data field. monitoring programs that do not reformat the data field. Internet
Internet addresses are represented as follows: IPv4 addresses are addresses are represented as follows: IPv4 addresses are written in
written in the form [n.n.n.n], where n is in decimal notation and the the form [n.n.n.n], where n is in decimal notation and the brackets
brackets are optional; IPv6 addresses are formulated based on the are optional; IPv6 addresses are formulated based on the guidelines
guidelines defined in [RFC5952]. Timestamps, including reference, defined in [RFC5952]. Timestamps, including reference, originate,
originate, receive and transmit values, as well as the logical clock, receive and transmit values, as well as the logical clock, are
are represented in units of seconds and fractions, preferably in represented in units of seconds and fractions, preferably in
hexadecimal notation. Delay, offset, dispersion and distance values hexadecimal notation. Delay, offset, dispersion and distance values
are represented in units of milliseconds and fractions, preferably in are represented in units of milliseconds and fractions, preferably in
decimal notation. All other values are represented as-is, preferably decimal notation. All other values are represented as-is, preferably
in decimal notation. 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 in the name. For those commands that return a list of assignments in
assignments in the response data field, if the command data field is the response data field, if the command data field is empty, it is
empty, it is expected that all available variables defined in RFC expected that all available variables defined in RFC 5905 will be
5905 will be included in the response. For the read commands, if the included in the response. For the read commands, if the command data
command data field is nonempty, an implementation may choose to field is nonempty, an implementation may choose to process this field
process this field to individually select which variables are to be to individually select which variables are to be returned.
returned.
Commands are interpreted as follows: Commands are interpreted as follows:
Read Status (1): The command data field is empty or contains a list Read Status (1): The command data field is empty or contains a list
of identifiers separated by commas. The command operates in two ways of identifiers separated by commas. The command operates in two ways
depending on the value of the association identifier. If this depending on the value of the association identifier. If this
identifier is nonzero, the response includes the peer identifier and identifier is nonzero, the response includes the peer identifier and
status word. Optionally, the response data field may contain other status word. Optionally, the response data field may contain other
information, such as described in the Read Variables command. If the information, such as described in the Read Variables command. If the
association identifier is zero, the response includes the system association identifier is zero, the response includes the system
identifier (0) and status word, while the data field contains a list identifier (0) and status word, while the data field contains a list
of binary-coded pairs <<association identifier>> <<status word>>, one of binary-coded pairs <<association identifier>> <<status word>>, one
for each currently defined association. for each currently defined association.
Read Variables (2): The command data field is empty or contains a Read Variables (2): The command data field is empty or contains a
list of identifiers separated by commas. If the association list of identifiers separated by commas. If the association
identifier is nonzero, the response includes the requested peer identifier is nonzero, the response includes the requested peer
identifier and status word, while the data field contains a list of identifier and status word, while the data field contains a list of
peer variables and values as described above. If the association peer variables and values as described above. If the association
identifier is zero, the data field contains a list of system identifier is zero, the data field contains a list of system
variables and values. If a peer has been selected as the variables. If a peer has been selected as the synchronization
synchronization source, the response includes the peer identifier and source, the response includes the peer identifier and status word;
status word; otherwise, the response includes the system identifier otherwise, the response includes the system identifier (0) and status
(0) and status word. word.
Write Variables (3): The command data field contains a list of Write Variables (3): The command data field contains a list of
assignments as described above. The variables are updated as assignments as described above. The variables are updated as
indicated. The response is as described for the Read Variables indicated. The response is as described for the Read Variables
command. command.
Read Clock Variables (4): The command data field is empty or contains Read Clock Variables (4): The command data field is empty or contains
a list of identifiers separated by commas. The association a list of identifiers separated by commas. The association
identifier selects the system clock variables or peer clock variables identifier selects the system clock variables or peer clock variables
in the same way as in the Read Variables command. The response in the same way as in the Read Variables command. The response
skipping to change at page 15, line 27 skipping to change at page 15, line 27
information can be included in the data field. information can be included in the data field.
Configure (8): The command data is parsed and applied as if supplied Configure (8): The command data is parsed and applied as if supplied
in the daemon configuration file. in the daemon configuration file.
Save Configuration (9): Write a snapshot of the current configuration Save Configuration (9): Write a snapshot of the current configuration
to the file name supplied as the command data. Further, the command to the file name supplied as the command data. Further, the command
is refused unless a directory in which to store the resulting files is refused unless a directory in which to store the resulting files
has been explicitly configured by the operator. has been explicitly configured by the operator.
Read MRU (10): Retrieves records of recently seen remote addresses Read Most Recently Used (MRU) list (10): Retrieves records of
and associated statistics. Command data consists of name=value pairs recently seen remote addresses and associated statistics. Command
controlling the selection of records, as well as a requestor-specific data consists of name=value pairs controlling the selection of
nonce previously retrieved using this command or opcode 12, Request records, as well as a requestor-specific nonce previously retrieved
Nonce. The response consists of name=value pairs where some names using this command or opcode 12, Request Nonce. The response
can appear multiple times using a dot followed by a zero-based index consists of name=value pairs where some names can appear multiple
to distinguish them, and to associate elements of the same record times using a dot followed by a zero-based index to distinguish them,
with the same index. A new nonce is provided with each successful and to associate elements of the same record with the same index. A
response. new nonce is provided with each successful response.
Read ordered list (11): Retrieves an ordered list. If the command Read ordered list (11): Retrieves a list ordered by IP address (IPv4
data is empty or the seven characters "ifstats" the associated information precedes IPv6 information). If the command data is empty
statistics, status and counters for each local address are returned. or the seven characters "ifstats", the associated statistics, status
If the command data is the characters "addr_restrictions" then the and counters for each local address are returned. If the command
set of IPv4 remote address restrictions followed by the set of IPv6 data is the characters "addr_restrictions" then the set of IPv4
remote address restrictions (access control lists) are returned. remote address restrictions followed by the set of IPv6 remote
Other command data returns error code 5 (unknown variable name). address restrictions (access control lists) are returned. Other
Similar to Read MRU, response information uses zero-based indexes as command data returns error code 5 (unknown variable name). Similar
part of the variable name preceding the equals sign and value, where to Read MRU, response information uses zero-based indexes as part of
each index relates information for a single address or network. This the variable name preceding the equals sign and value, where 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. Inclusion of the nonce by a managment agent between daemon runs. Inclusion of the nonce by a management agent
demonstrates to the server that the agent can receive datagrams sent demonstrates to the server that the agent can receive datagrams sent
to the source address of the request, making source address to the source address of the request, making source address
"spoofing" more difficult in a similar way as TCP's three-way "spoofing" more difficult in a similar way as TCP's three-way
handshake. 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.
skipping to change at page 16, line 35 skipping to change at page 16, line 37
A number of security vulnerabilities have been identified with these A number of security vulnerabilities have been identified with these
control messages. control messages.
NTP's control query interface allows reading and writing of system, NTP's control query interface allows reading and writing of system,
peer, and clock variables remotely from arbitrary IP addresses using peer, and clock variables remotely from arbitrary IP addresses using
commands mentioned in Section 4. Traditionally, overwriting these commands mentioned in Section 4. Traditionally, overwriting these
variables, but not reading them, requires authentication by default. variables, but not reading them, requires authentication by default.
However, this document argues that an NTP host must authenticate all However, this document argues that an NTP host must authenticate all
control queries and not just ones that overwrite these variables. control queries and not just ones that overwrite these variables.
Alternatively, the host can use a whitelist to explicitly list IP Alternatively, the host can use an access control list to explicitly
addresses that are allowed to control query the clients. These list IP addresses that are allowed to control query the clients.
access controls are required for the following reasons: These 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-DOS]). These attacks only use in response to a small query [CVE-DOS]). These attacks only use
NTP as a vector for DoS atacks on other protocols, but do not NTP as a vector for DoS attacks 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 [RFC3704].
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.
skipping to change at page 17, line 45 skipping to change at page 17, line 47
for reconnaissance and a spoofed response to shift time on for reconnaissance and a spoofed response to shift time on
vulnerable clients. vulnerable clients.
o The mode 6 and 7 messages are vulnerable to replay attacks o The mode 6 and 7 messages are vulnerable to replay attacks
[CVE-Replay]. If an attacker observes mode 6/7 packets that [CVE-Replay]. If an attacker observes mode 6/7 packets that
modify the configuration of the server in any way, the attacker modify the configuration of the server in any way, the attacker
can apply the same change at any time later simply by sending the can apply the same change at any time later simply by sending the
packets to the server again. The use of the nonce (Request Nonce packets to the server again. The use of the nonce (Request Nonce
command) provides limited protection against replay attacks. command) provides limited protection against replay attacks.
NTP best practices recommend configuring ntpd with the no-query NTP best practices recommend configuring NTP 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 hosts 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.
Significantly fewer hosts respond to mode 7 monlist queries as Significantly fewer hosts respond to mode 7 monlist queries as
compared to other control queries because it is a well-known and compared to other control queries because it is a well-known and
skipping to change at page 18, line 49 skipping to change at page 19, line 5
9. References 9. References
9.1. Normative 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: [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Defeating Denial of Service Attacks which employ IP Source Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2004, <https://www.rfc-editor.org/info/rfc3704>.
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 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
skipping to change at page 19, line 40 skipping to change at page 19, line 44
[CVE-SPOOF] [CVE-SPOOF]
NIST National Vulnerability Database, "CVE-2015-8139, NIST National Vulnerability Database, "CVE-2015-8139,
https://nvd.nist.gov/vuln/detail/CVE-2015-8139", January https://nvd.nist.gov/vuln/detail/CVE-2015-8139", January
2017. 2017.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
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 26 skipping to change at page 20, line 28
| Encryption KeyID (when A bit set) | | Encryption KeyID (when A bit set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Message Authentication Code (when A bit set) / / Message Authentication Code (when A bit set) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP Remote Facility Message Header Figure 3: NTP Remote Facility Message Header
Response Bit (R) : Set to 0 if the packet is a request. Set to 1 if Response Bit (R) : Set to 0 if the packet is a request. Set to 1 if
the packet is a reponse. the packet is a response.
More Bit (M) : Set to 0 if this is the last packet in a response, More Bit (M) : Set to 0 if this is the last packet in a response,
otherwise set to 1 in responses requiring more then one packet. otherwise set to 1 in responses requiring more than one packet.
Version Number (VN) : Set to the version number of the NTP daemon. Version Number (VN) : Set to the version number of the NTP daemon.
Mode : Set to 7 for Remote Facility messages. Mode : Set to 7 for Remote Facility messages.
Authenticated Bit (A) : If set to 1, this packet contains Authenticated Bit (A) : If set to 1, this packet contains
authentication information. authentication information.
Sequence : For a multi-packet response, this field contains the Sequence : For a multi-packet response, this field contains the
sequence number of this packet. Packets in a multi-packet response sequence number of this packet. Packets in a multi-packet response
 End of changes. 32 change blocks. 
92 lines changed or deleted 98 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/