< draft-ietf-ntp-mode-6-cmds-02.txt   draft-ietf-ntp-mode-6-cmds-03.txt >
Network Working Group D. Mills Network Working Group D. Mills
Internet-Draft University of Deleware Internet-Draft University of Delaware
Intended status: Informational B. Haberman, Ed. Intended status: Informational B. Haberman, Ed.
Expires: January 20, 2018 JHU Expires: March 22, 2018 JHU
July 19, 2017 September 18, 2017
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-02 draft-ietf-ntp-mode-6-cmds-03
Abstract Abstract
This document describes the structure of the control messages used This document describes the structure of the control messages used
with the Network Time Protocol. These control messages can be used with the Network Time Protocol. These control messages can be used
to monitor and control the Network Time Protocol application running to monitor and control the Network Time Protocol application running
on any IP network attached computer. The information in this on any IP network attached computer. The information in this
document was originally described in Appendix B of RFC 1305. The document was originally described in Appendix B of RFC 1305. The
goal of this document is to provide a historic description of the goal of this document is to provide a historic description of the
control messages. control messages.
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 http://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 January 20, 2018. This Internet-Draft will expire on March 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . 4
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. NTP Remote Facility Message Format . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Normative References . . . . . . . . . . . . . . . . . . . . 18
9. Normative References . . . . . . . . . . . . . . . . . . . . 20 Appendix A. NTP Remote Facility Message Format . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 4, line 32 skipping to change at page 4, line 32
limit access for control messages (mode 6) to selected address limit access for control messages (mode 6) to selected address
ranges. 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 (ntpdc) for monitoring and configuration. This facility used mode 7
commands to communicate with the NTP daemon. This document commands to communicate with the NTP daemon. This document
illustrates the mode 7 packet format only. The commands embedded in illustrates the mode 7 packet format only. The commands embedded in
the mode 7 messages are implementation specific and not standardized the mode 7 messages are implementation specific and not standardized
in any way. The mode 7 message format is shown in Figure 3. in any way. 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. Bit positions marked as zero are reserved
and should always be transmitted as zero. 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 5, line 21 skipping to change at page 5, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count | | Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data (up to 468 bytes) / / Data (up to 468 bytes) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) | | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Authenticator (optional, 96 bytes) / / Authenticator (optional, 96 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 as this position in mot NTP modes is in the System Status Word used as this position in mot 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 16, line 22 skipping to change at page 16, line 22
nonce by a managment agent demonstrates to the server that the agent nonce by a managment agent demonstrates to the server that the agent
can receive datagrams sent to the source address of the request, can receive datagrams sent to the source address of the request,
making source address "spoofing" more difficult in a similar way as making source address "spoofing" more difficult in a similar way as
TCP's three-way handshake. TCP's 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. NTP Remote Facility Message Format 5. IANA Considerations
The format of the NTP Remote Facility Message header, which
immediately follows the UDP header, is shown in Figure 3. Following
is a description of its fields. Bit positions marked as zero are
reserved and should always be transmitted as zero.
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) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP Remote Facility Message Header
Response Bit (R) : Set to 0 if the packet is a request. Set to 1 if
the packet is a reponse.
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.
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 which
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 non-
zero, 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.
6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 6. Security Considerations
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.
skipping to change at page 20, line 16 skipping to change at page 18, line 16
middleboxes rather than the no-query option on NTP hosts. The middleboxes rather than the no-query option on NTP hosts. The
remaining control queries that can be exploited likely remain out of remaining control queries that can be exploited likely remain out of
the blacklist because they are undocumented in the current NTP the blacklist because they are 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.
8. Acknowledgements 7. 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.
9. Normative References 8. 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,
<http://www.rfc-editor.org/info/rfc1305>. <https://www.rfc-editor.org/info/rfc1305>.
[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,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
Appendix A. NTP Remote Facility Message Format
The format of the NTP Remote Facility Message header, which
immediately follows the UDP header, is shown in Figure 3. Following
is a description of its fields. Bit positions marked as zero are
reserved and should always be transmitted as zero.
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) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP Remote Facility Message Header
Response Bit (R) : Set to 0 if the packet is a request. Set to 1 if
the packet is a reponse.
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.
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 which
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 non-
zero, 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.
Authors' Addresses Authors' Addresses
Dr. David L. Mills Dr. David L. Mills
University of Deleware University of Delaware
Email: mills@udel.edu Email: mills@udel.edu
Brian Haberman (editor) Brian Haberman (editor)
JHU JHU
Email: brian@innovationslab.net Email: brian@innovationslab.net
 End of changes. 17 change blocks. 
115 lines changed or deleted 114 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/