< draft-haberman-ntpwg-mode-6-cmds-01.txt   draft-haberman-ntpwg-mode-6-cmds-02.txt >
Network Working Group D. Mills Network Working Group D. Mills
Internet-Draft University of Deleware Internet-Draft University of Deleware
Intended status: Historic B. Haberman, Ed. Intended status: Historic B. Haberman, Ed.
Expires: January 23, 2017 July 22, 2016 Expires: April 20, 2017 JHU
October 17, 2016
Control Messages Protocol for Use with Network Time Protocol Version 4 Control Messages Protocol for Use with Network Time Protocol Version 4
draft-haberman-ntpwg-mode-6-cmds-01 draft-haberman-ntpwg-mode-6-cmds-02
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.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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 http://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 23, 2017. This Internet-Draft will expire on April 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 21
1.1. Control Message Overview . . . . . . . . . . . . . . . . 2 1.1. Control Message Overview . . . . . . . . . . . . . . . . 2
2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4 2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4
3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. System Status Word . . . . . . . . . . . . . . . . . . . 6 3.1. System Status Word . . . . . . . . . . . . . . . . . . . 6
3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 8 3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 8
3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 9 3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 9
3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 10 3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 10
4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 12, line 46 skipping to change at page 12, line 46
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.
6. 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,
peer, and clock variables remotely from arbitrary IP addresses using
commands mentioned in Section 4. Traditionally, overwriting these
variables, but not reading them, requires authentication by default.
However, this document argues that an NTP host must authenticate all
control queries and not just ones that overwrite these variables.
Alternatively, the host can use a whitelist to explicitly list IP
addresses that are allowed to control query the clients. These
access controls are required for the following reasons:
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
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 DDoS 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-2013-5211)). These attacks only
use NTP as a vector for DoS atacks on other protocols, but do not
affect the time service on the NTP host itself.
o 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 DoS 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.
CVE-2015-8139 describes the specific attack.
* 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. CVE-
2016-1548 describes the attack.
o 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. CVE-2016-1548 is one such example.
NTP best practices recommend configuring ntpd with the no-query
parameter. The no-query parameter blocks access to all remote
control queries. However, sometimes the nosts do not want to block
all queries and want to give access for certain control queries
remotely. This could be for the purpose of remote management and
configuration of the hosts in certain scenarios. Such hosts tend to
use firewalls or other middleboxes to blacklist certain queries
within the network.
Recent work (reference needed) shows that significantly fewer hosts
respond to mode 7 monlist queries as compared to other control
queries because it is a well-known and exploited control query.
These queries are likely blocked using blacklists on firewalls and
middleboxes rather than the no-query option on NTP hosts. The
remaining control queries that can be exploited likely remain out of
the blacklist because they are undocumented in the current NTP
specification [RFC5905].
This document describes all of the mode 6 control queries allowed by
NTP and can help administrators make informed decisions on security
measures to protect NTP devices from harmful queries and likely make
those systems less vulnerable.
7. Acknowledgements 7. Acknowledgements
Tim Plunkett created the original version of this document. Tim Plunkett created the original version of this document. Aanchal
Malhotra provided the initial version of the Security Considerations
section.
8. 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>. <http://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
skipping to change at page 13, line 23 skipping to change at page 15, line 4
"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>. <http://www.rfc-editor.org/info/rfc5905>.
Authors' Addresses Authors' Addresses
Dr. David L. Mills Dr. David L. Mills
University of Deleware University of Deleware
Email: mills@udel.edu Email: mills@udel.edu
Brian Haberman (editor) Brian Haberman (editor)
JHU
Email: brian@innovationslab.net Email: brian@innovationslab.net
 End of changes. 8 change blocks. 
8 lines changed or deleted 90 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/