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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI |  VN |Mode |R|E|M| opcode  |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Status             |       Association ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Offset             |            Count              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                    Data (up to 468 bytes)                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Padding (optional)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/              Authenticator (optional, 20 or 24 bits)          /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Leap Indicator (LI):

This is a 2-bit integer that is set to b00 for control message requests and responses. The Leap Indicator value used at this position in most NTP modes is in the system status word provided in some control message responses.

Version Number (VN):

This is a 3-bit integer indicating a minimum NTP version number. NTP servers do not respond to control messages with an unrecognized version number. Requests may intentionally use a lower version number to enable interoperability with earlier versions of NTP. Responses carry the same version as the corresponding request.

Mode:

This is a 3-bit integer indicating the mode. The value 6 indicates an NTP control message.

Response Bit (R):

Set to zero for commands; set to one for responses.

Error Bit (E):

Set to zero for normal responses; set to one for an error response.

More Bit (M):

Set to zero for the last fragment; set to one for all others.

Operation Code (opcode):

This is a 5-bit integer specifying the command function. Values currently defined include the following:

Sequence Number:

This is a 16-bit integer indicating the sequence number of the command or response. Each request uses a different sequence number. Each response carries the same sequence number as its corresponding request. For asynchronous trap responses, the responder increments the sequence number by one for each response, allowing trap receivers to detect missing trap responses. The sequence number of each fragment of a multiple-datagram response carries the same sequence number, copied from the request.

Status:

This is a 16-bit code indicating the current status of the system, peer, or clock with values coded as described in following sections.

Association ID:

This is a 16-bit unsigned integer identifying a valid association or zero for the system clock.

Offset:

This is a 16-bit unsigned integer indicating the offset, in octets, of the first octet in the data area. The offset is set to zero in requests. Responses spanning multiple datagrams use a positive offset in all but the first datagram.

Count:

This is a 16-bit unsigned integer indicating the length of the data field, in octets.

Data:

This contains the message data for the command or response. The maximum number of data octets is 468.

Padding (optional):

Contains zero to 3 octets with a value of zero, as needed to ensure the overall control message size is a multiple of 4 octets.

Authenticator (optional):

When the NTP authentication mechanism is implemented, this contains the authenticator information defined in Appendix C of RFC 1305.

Leap Indicator (LI):

This is a 2-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current day, with bit 0 and bit 1, respectively, coded as follows:

Clock Source (Clock Src):

This is a 6-bit integer indicating the current synchronization source, with values coded as follows:

System Event Counter (Count):

This is a 4-bit integer indicating the number of system events occurring since the last time the System Event Code changed. Upon reaching 15, subsequent events with the same code are not counted.

System Event Code (Code):

This is a 4-bit integer identifying the latest system exception event, with new values overwriting previous values, and coded as follows:

Peer Status (Status):

This is a 5-bit code indicating the status of the peer determined by the packet procedure, with bits assigned as follows:

Peer Selection (SEL):

This is a 3-bit integer indicating the status of the peer determined by the clock-selection procedure, with values coded as follows:

Peer Event Counter (Count):

This is a 4-bit integer indicating the number of peer exception events that occurred since the last time the peer event code changed. Upon reaching 15, subsequent events with the same code are not counted.

Peer Event Code (Code):

This is a 4-bit integer identifying the latest peer exception event, with new values overwriting previous values, and coded as follows:

Reserved:

This is an 8-bit integer that is ignored by requesters and zeroed by responders.

Count:

This is a 4-bit integer indicating the number of clock events that occurred since the last time the clock event code changed. Upon reaching 15, subsequent events with the same code are not counted.

Clock Code (Code):

This is a 4-bit integer indicating the current clock status, with values coded as follows:

• IPv4 internet addresses are written in the form [n.n.n.n], where n is in decimal notation and the brackets are optional
• IPv6 internet addresses are formulated based on the guidelines defined in [RFC 5952].
• Timestamps (including reference, originate, receive, and transmit values) and the logical clock are represented in units of seconds and fractions, preferably in hexadecimal notation.
• Delay, offset, dispersion, and distance values are represented in units of milliseconds and fractions, preferably in decimal notation.
• All other values are represented as is, preferably in decimal notation.

Read Status (1):

The command data field is empty or contains a list of identifiers separated by commas. The command operates in two ways depending on the value of the Association ID. If this identifier is nonzero, the response includes the peer identifier and status word. Optionally, the response data field may contain other information, such as described in the Read Variables command. If the association identifier is zero, the response includes the system identifier (0) and status word; the data field contains a list of binary-coded pairs <<Association ID>> <<status word>>, one for each currently defined association.

Read Variables (2):

The command data field is empty or contains a list of identifiers separated by commas. If the Association ID is nonzero, the response includes the requested peer identifier and status word; the data field contains a list of peer variables and values as described above. If the Association ID is zero, the data field contains a list of system variables. If a peer has been selected as the synchronization source, the response includes the peer identifier and status word; otherwise, the response includes the system identifier (0) and status word.

Write Variables (3):

The command data field contains a list of assignments as described above. The variables are updated as indicated. The response is as described for the Read Variables command.

Read Clock Variables (4):

The command data field is empty or contains a list of identifiers separated by commas. The Association ID selects the system clock variables or peer clock variables in the same way as in the Read Variables command. The response includes the requested clock identifier and status word; the data field contains a list of clock variables and values, including the last timecode message received from the clock.

Write Clock Variables (5):

The command data field contains a list of assignments as described above. The clock variables are updated as indicated. The response is as described for the read clock variables command.

Set Trap Address/Port (6):

The command Association ID, status, and data fields are ignored. The address and port number for subsequent trap messages are taken from the source address and port of the control message itself. The initial trap counter for trap response messages is taken from the sequence field of the command. The response association identifier, status, and data fields are not significant. Implementations should include logical timeouts that prevent trap transmissions if the monitoring program does not renew this information after a lengthy interval.

Trap Response (7):

This message is sent when a system, peer, or clock exception event occurs. The opcode field is 7 and the R bit is set. The trap counter is incremented by one for each trap sent and the sequence field set to that value. The trap message is sent using the IP address and port fields established by the set trap address/port command. If a system trap, the Association ID field is set to zero and the status field contains the system status word. If a peer trap, the Association ID field is set to that peer and the status field contains the peer status word. Optional ASCII-coded information can be included in the data field.

Configure (8):

The command data is parsed and applied as if supplied in the daemon configuration file.

Save Configuration (9):

Writes a snapshot of the current configuration to the file name supplied as the command data. Further, the command is refused unless a directory in which to store the resulting files has been explicitly configured by the operator.

Read Most Recently Used (MRU) list (10):

Retrieves records of recently seen remote addresses and associated statistics. This command supports all of the state variables defined in Section 9 of RFC 5905. Command data consists of name=value pairs controlling the selection of records, as well as a requestor-specific nonce previously retrieved using this command or opcode 12 (Request Nonce). The response consists of name=value pairs where some names can appear multiple times using a dot followed by a zero-based index to distinguish them and to associate elements of the same record with the same index. A new nonce is provided with each successful response.

Read ordered list (11):

Retrieves a list ordered by IP address (IPv4 information precedes IPv6 information). If the command data is empty or is the seven characters "ifstats", the associated statistics, status, and counters for each local address are returned. If the command data is the characters "addr_restrictions", then the set of IPv4 remote address restrictions followed by the set of IPv6 remote address restrictions (access control lists) are returned. Other command data returns error code 5 (unknown variable name). Similar to Read MRU, response information uses zero-based indexes as part of the variable name preceding the equals sign and value, where each index relates information for a single address or network. This opcode requires authentication.

Request Nonce (12):

Retrieves a 96-bit nonce specific to the requesting remote address, which is valid for a limited period. 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, the remote address, and salt known only to the server, which varies between daemon runs. Inclusion of the nonce by a management agent demonstrates to the server that the agent can receive datagrams sent to the source address of the request, making source address "spoofing" more difficult in a similar way as TCP's three-way handshake.

Unset Trap (31):

Removes the requesting remote address and port from 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 error code is 4 (bad association).

NTP as a Distributed Denial-of-Service (DDoS) vector:

NTP timing query and response packets (modes 1-2, 3-4, and 5) are usually short in size. However, some NTP control queries generate a very long 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 perform DoS attacks. These off-path attacks exploit the large size of NTP control queries to cause UDP-based amplification attacks (e.g., mode 7 monlist command generates a very long packet in response to a small query [CVE-DOS]). These attacks only use 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 sources of these malicious commands, NTP server operators are recommended to deploy ingress filtering [RFC 3704].

Time-shifting attacks through information leakage/overwriting:

NTP hosts save important system and peer state variables. An off-path attacker who can read these variables remotely can leverage the information leaked by these control queries to perform time-shifting and DDoS attacks on NTP clients. These attacks do affect time synchronization on the NTP hosts. For instance:

• In the client/server mode, the client stores its local time when it sends the query to the server in its xmt peer variable. This variable is used to perform TEST2 to non-cryptographically authenticate the server (i.e., if the origin timestamp field in the corresponding server response packet matches the xmt peer variable, then the client accepts the packet). An off-path attacker with the ability to read this variable can easily spoof server response packets for the client, which will pass TEST2 and can deny service or shift time on the NTP client. The specific attack is described in [CVE-SPOOF].
• The client also stores its local time when the server response is received in its rec peer variable. This variable is used for authentication in interleaved-pivot mode. An off-path attacker with the ability to read this state variable can easily shift time on the client by passing this test. This attack is described in [CVE-SHIFT].

Fast-Scanning:

NTP mode 6 control messages are usually small UDP packets. Fast-scanning tools like ZMap can be used to spray the entire (potentially reachable) Internet with these messages within hours to identify vulnerable hosts. To make things worse, these attacks can be extremely low-rate, only requiring a control query for reconnaissance and a spoofed response to shift time on vulnerable clients.

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 by simply sending the packets to the server again. The use of the nonce (Request Nonce command) provides limited protection against replay attacks.

[RFC1305]

D. Mills, "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3704]

F. Baker, and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004,
<https://www.rfc-editor.org/info/rfc3704>.

[RFC5905]

D. Mills, J. Martin, J. Burbank, and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.

[RFC5952]

S. Kawamura, 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>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[CVE-DOS]

NIST National Vulnerability Database, "CVE-2013-5211 Detail", January 2014,
<https://nvd.nist.gov/vuln/detail/CVE-2013-5211>.

[CVE-Replay]

NIST National Vulnerability Database, "CVE-2015-8140 Detail", January 2015,
<https://nvd.nist.gov/vuln/detail/CVE-2015-8140>.

[CVE-SHIFT]

NIST National Vulnerability Database, "CVE-2016-1548 Detail", January 2017,
<https://nvd.nist.gov/vuln/detail/CVE-2016-1548>.

[CVE-SPOOF]

NIST National Vulnerability Database, "CVE-2015-8139 Detail", January 2017,
<https://nvd.nist.gov/vuln/detail/CVE-2015-8139>.

[RFC0791]

J. Postel, "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|M| VN  |Mode |A|  Sequence   | Implementation|   Req Code    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Err  |        Count          |  MBZ  |       Size            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                    Data (up to 500 bytes)                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Encryption KeyID (when A bit set)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/          Message Authentication Code (when A bit set)         /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Response Bit (R):

Set to 0 if the packet is a request. Set to 1 if the packet is 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 than one packet.

Version Number (VN):

Set to the version number of the NTP daemon.

Mode:

Set to 7 for Remote Facility messages.

Authenticated Bit (A):

If set to 1, this packet contains authentication information.

Sequence:

For a multi-packet response, this field contains the sequence number of this packet. Packets in a multi-packet response are numbered starting with 0. The More Bit is set to 1 for all packets but the last.

Implementation:

The version number of the implementation that defined the request code used in this message. An implementation number of 0 is used for a request code supported by all versions of the NTP daemon. The value 255 is reserved for future extensions.

Request Code (Req Code):

An implementation-specific code that specifies the operation being requested. A request code definition includes the format and semantics of the data included in the packet.

Error (Err):

Set to 0 for a request. For a response, this field contains an error code relating to the request. If the Error is nonzero, the operation requested wasn't performed.

0:

no error

1:

incompatible implementation number

2:

unimplemented request code

3:

format error

4:

no data available

7:

authentication failure

Count:

The number of data items in the packet. Range is 0 to 500.

Must Be Zero (MBZ):

A reserved field set to 0 in requests and responses.

Size:

The size of each data item in the packet. Range is 0 to 500.

Data:

A variable-sized field containing request/response data. For requests and responses, the size in octets must be greater than or equal to the product of the number of data items (Count) and the size of a data item (Size). For requests, the data area is exactly 40 octets in length. For responses, the data area will range from 0 to 500 octets, inclusive.

Encryption KeyID:

A 32-bit unsigned integer used to designate the key used for the Message Authentication Code. This field is included only when the A bit is set to 1.

Message Authentication Code:

An optional Message Authentication Code defined by the version of the NTP daemon indicated in the Implementation field. This field is included only when the A bit is set to 1.

Brian Haberman