< draft-ietf-ntp-mode-6-cmds-07.txt   draft-ietf-ntp-mode-6-cmds-08.txt >
Network Working Group B. Haberman, Ed. Network Working Group B. Haberman, Ed.
Internet-Draft JHU Internet-Draft JHU
Intended status: Historic November 19, 2019 Intended status: Historic June 1, 2020
Expires: May 22, 2020 Expires: December 3, 2020
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-07 draft-ietf-ntp-mode-6-cmds-08
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 a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 May 22, 2020. This Internet-Draft will expire on December 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. NTP Remote Facility Message Format . . . . . . . . . 19 Appendix A. NTP Remote Facility Message Format . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
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
skipping to change at page 11, line 10 skipping to change at page 11, line 10
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
values coded as follows: values coded as follows:
+-----+-------------------------------------------------------------+ +-----+-------------------------------------------------------------+
| Sel | Meaning | | Sel | Meaning |
+-----+-------------------------------------------------------------+ +-----+-------------------------------------------------------------+
| 0 | rejected | | 0 | rejected |
| 1 | discarded by intersection algorithm | | 1 | discarded by intersection algorithm |
| 2 | discarded bu table overflow (not currently used) | | 2 | discarded by table overflow (not currently used) |
| 3 | discarded by the cluster algorithm | | 3 | discarded by the cluster algorithm |
| 4 | included by the combine algorithm | | 4 | included by the combine algorithm |
| 5 | backup source (with more than sys.maxclock survivors) | | 5 | backup source (with more than sys.maxclock survivors) |
| 6 | system peer (synchronization source) | | 6 | system peer (synchronization source) |
| 7 | PPS (pulse per second) peer | | 7 | PPS (pulse per second) peer |
+-----+-------------------------------------------------------------+ +-----+-------------------------------------------------------------+
Peer Event Counter (Count): This is a four-bit integer indicating the Peer Event Counter (Count): This is a four-bit integer indicating the
number of peer exception events that occurred since the last time the number of peer exception events that occurred since the last time the
peer event code changed. Upon reaching 15, subsequent events with peer event code changed. Upon reaching 15, subsequent events with
skipping to change at page 11, line 34 skipping to change at page 11, line 34
latest peer exception event, with new values overwriting previous latest peer exception event, with new values overwriting previous
values, and coded as follows: values, and coded as follows:
+-------+--------------------------------------------------------+ +-------+--------------------------------------------------------+
| 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 ntpd -q) |
| 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 |
+-------+--------------------------------------------------------+ +-------+--------------------------------------------------------+
3.3. Clock Status Word 3.3. Clock Status Word
There are two ways a reference clock can be attached to a NTP service There are two ways a reference clock can be attached to a NTP service
host, as an dedicated device managed by the operating system and as a host, as a dedicated device managed by the operating system and as a
synthetic peer managed by NTP. As in the read status command, the synthetic peer managed by NTP. As in the read status command, the
association identifier is used to identify which one, zero for the association identifier is used to identify which one, zero for the
system clock and nonzero for a peer clock. Only one system clock is system clock and nonzero for a peer clock. Only one system clock is
supported by the protocol, although many peer clocks can be supported by the protocol, although many peer clocks can be
supported. A system or peer clock status word appears in the status supported. A system or peer clock status word appears in the status
field of the response to a read clock variables or write clock field of the response to a read clock variables or write clock
variables command. This word can be considered an extension of the variables command. This word can be considered an extension of the
system status word or the peer status word as appropriate. The system status word or the peer status word as appropriate. The
format of the clock status word is as follows: format of the clock status word is as follows:
skipping to change at page 17, line 46 skipping to change at page 17, line 46
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. 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. packets to the server again. The use of the nonce (Request Nonce
command) provides limited protection against replay attacks.
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 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.
skipping to change at page 18, line 21 skipping to change at page 18, line 22
exploited control query. These queries are likely blocked using exploited control query. These queries are likely blocked using
blacklists on firewalls and middleboxes rather than the no-query blacklists on firewalls and middleboxes rather than the no-query
option on NTP hosts. The remaining control queries that can be option on NTP hosts. The remaining control queries that can be
exploited likely remain out of the blacklist because they are exploited likely remain out of the blacklist because they are
undocumented in the current NTP specification [RFC5905]. undocumented in the current NTP 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. Regardless of which mode 6 commands those systems less vulnerable. Regardless of which mode 6 commands
an administrator elect to allow, remote access to this facility needs an administrator may elect to allow, remote access to this facility
to be protected from unauthorized access (e.g., strict ACLs). needs to be protected from unauthorized access (e.g., strict ACLs).
7. Contributors 7. Contributors
Dr. David Mills specified the vast majority of the mode 6 commands Dr. David Mills specified the vast majority of the mode 6 commands
during the development of RFC 1305 [RFC1305] and deserves the credit during the development of RFC 1305 [RFC1305] and deserves the credit
for their existence and use. for their existence and use.
8. Acknowledgements 8. Acknowledgements
Tim Plunkett created the original version of this document. Aanchal Tim Plunkett created the original version of this document. Aanchal
 End of changes. 10 change blocks. 
13 lines changed or deleted 14 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/