idnits 2.17.1 draft-haberman-ntpwg-mode-6-cmds-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2016) is 2738 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Mills 3 Internet-Draft University of Deleware 4 Intended status: Historic B. Haberman, Ed. 5 Expires: April 20, 2017 JHU 6 October 17, 2016 8 Control Messages Protocol for Use with Network Time Protocol Version 4 9 draft-haberman-ntpwg-mode-6-cmds-02 11 Abstract 13 This document describes the structure of the control messages used 14 with the Network Time Protocol. These control messages can be used 15 to monitor and control the Network Time Protocol application running 16 on any IP network attached computer. The information in this 17 document was originally described in Appendix B of RFC 1305. The 18 goal of this document is to provide a historic description of the 19 control messages. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 20, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Control Message Overview . . . . . . . . . . . . . . . . 2 57 2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4 58 3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. System Status Word . . . . . . . . . . . . . . . . . . . 6 60 3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 8 61 3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 9 62 3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 10 63 4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 RFC 1305 [RFC1305] described a set of control messages for use within 73 the Network Time Protocol (NTP) when a comprehensive network 74 management solution was not available. The definitions of these 75 control messages were not promulgated to RFC 5905 [RFC5905] when NTP 76 version 4 was documented. These messages were intended for use only 77 in systems where no other management facilities were available or 78 appropriate, such as in dedicated-function bus peripherals. Support 79 for these messages is not required in order to conform to RFC 5905 80 [RFC5905]. The control messages are described here as a historical 81 record given their use within NTPv4. 83 1.1. Control Message Overview 85 The NTP Control Message has the value 6 specified in the mode field 86 of the first octet of the NTP header and is formatted as shown in 87 Figure 1. The format of the data field is specific to each command 88 or response; however, in most cases the format is designed to be 89 constructed and viewed by humans and so is coded in free-form ASCII. 90 This facilitates the specification and implementation of simple 91 management tools in the absence of fully evolved network-management 92 facilities. As in ordinary NTP messages, the authenticator field 93 follows the data field. If the authenticator is used the data field 94 is zero-padded to a 32-bit boundary, but the padding bits are not 95 considered part of the data field and are not included in the field 96 count. 98 IP hosts are not required to reassemble datagrams larger than 576 99 octets; however, some commands or responses may involve more data 100 than will fit into a single datagram. Accordingly, a simple 101 reassembly feature is included in which each octet of the message 102 data is numbered starting with zero. As each fragment is transmitted 103 the number of its first octet is inserted in the offset field and the 104 number of octets is inserted in the count field. The more-data (M) 105 bit is set in all fragments except the last. 107 Most control functions involve sending a command and receiving a 108 response, perhaps involving several fragments. The sender chooses a 109 distinct, nonzero sequence number and sets the status field and R and 110 E bits to zero. The responder interprets the opcode and additional 111 information in the data field, updates the status field, sets the R 112 bit to one and returns the three 32-bit words of the header along 113 with additional information in the data field. In case of invalid 114 message format or contents the responder inserts a code in the status 115 field, sets the R and E bits to one and, optionally, inserts a 116 diagnostic message in the data field. 118 Some commands read or write system variables and peer variables for 119 an association identified in the command. Others read or write 120 variables associated with a radio clock or other device directly 121 connected to a source of primary synchronization information. To 122 identify which type of variable and association a 16-bit association 123 identifier is used. System variables are indicated by the identifier 124 zero. As each association is mobilized a unique, nonzero identifier 125 is created for it. These identifiers are used in a cyclic fashion, 126 so that the chance of using an old identifier which matches a newly 127 created association is remote. A management entity can request a 128 list of current identifiers and subsequently use them to read and 129 write variables for each association. An attempt to use an expired 130 identifier results in an exception response, following which the list 131 can be requested again. 133 Some exception events, such as when a peer becomes reachable or 134 unreachable, occur spontaneously and are not necessarily associated 135 with a command. An implementation may elect to save the event 136 information for later retrieval or to send an asynchronous response 137 (called a trap) or both. In case of a trap the IP address and port 138 number is determined by a previous command and the sequence field is 139 set as described below. Current status and summary information for 140 the latest exception event is returned in all normal responses. Bits 141 in the status field indicate whether an exception has occurred since 142 the last response and whether more than one exception has occurred. 144 Commands need not necessarily be sent by an NTP peer, so ordinary 145 access-control procedures may not apply; however, the optional mask/ 146 match mechanism suggested elsewhere in this document provides the 147 capability to control access by mode number, so this could be used to 148 limit access for control messages (mode 6) to selected address 149 ranges. 151 2. NTP Control Message Format 153 The format of the NTP Control Message header, which immediately 154 follows the UDP header, is shown in Figure 1. Following is a 155 description of its fields. Bit positions marked as zero are reserved 156 and should always be transmitted as zero. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |0|0| VN |Mode |R|E|M| OpCode | Sequence Number | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Status | Association ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Offset | Count | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 / Data (up to 468 bytes) / 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 / Authenticator (optional, 96 bytes) / 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1: NTP Control Message Header 178 Version Number (VN): This is a three-bit integer indicating the NTP 179 version number, currently four (4). 181 Mode: This is a three-bit integer indicating the mode. The value 6 182 indicates an NTP control message. 184 Response Bit (R): Set to zero for commands, one for responses. 186 Error Bit (E): Set to zero for normal response, one for error 187 response. 189 More Bit (M): Set to zero for last fragment, one for all others. 191 Operation Code (OpCode): This is a five-bit integer specifying the 192 command function. Values currently defined include the following: 194 +-------+--------------------------------------------------+ 195 | Code | Meaning | 196 +-------+--------------------------------------------------+ 197 | 0 | reserved | 198 | 1 | read status command/response | 199 | 2 | read variables command/response | 200 | 3 | write variables command/response | 201 | 4 | read clock variables command/response | 202 | 5 | write clock variables command/response | 203 | 6 | set trap address/port command/response | 204 | 7 | trap response | 205 | 8-31 | reserved | 206 +-------+--------------------------------------------------+ 208 Sequence Number: This is a 16-bit integer indicating the sequence 209 number of the command or response. 211 Status: This is a 16-bit code indicating the current status of the 212 system, peer or clock, with values coded as described in following 213 sections. 215 Association ID: This is a 16-bit integer identifying a valid 216 association. 218 Offset: This is a 16-bit integer indicating the offset, in octets, of 219 the first octet in the data area. 221 Count: This is a 16-bit integer indicating the length of the data 222 field, in octets. 224 Data: This contains the message data for the command or response. 225 The maximum number of data octets is 468. 227 Authenticator (optional): When the NTP authentication mechanism is 228 implemented, this contains the authenticator information defined in 229 Appendix C of RFC 1305. 231 3. Status Words 233 Status words indicate the present status of the system, associations 234 and clock. They are designed to be interpreted by network-monitoring 235 programs and are in one of four 16-bit formats shown in Figure 2 and 236 described in this section. System and peer status words are 237 associated with responses for all commands except the read clock 238 variables, write clock variables and set trap address/port commands. 239 The association identifier zero specifies the system status word, 240 while a nonzero identifier specifies a particular peer association. 241 The status word returned in response to read clock variables and 242 write clock variables commands indicates the state of the clock 243 hardware and decoding software. A special error status word is used 244 to report malformed command fields or invalid values. 246 0 1 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | LI| Clock Src | Count | Code | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 System Status Word 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Status | SEL | Count | Code | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Peer Status Word 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Clock Status | Code | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Radio Status Word 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Error Code | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Error Status Word 268 Figure 2: Status Word Formats 270 3.1. System Status Word 272 The system status word appears in the status field of the response to 273 a read status or read variables command with a zero association 274 identifier. The format of the system status word is as follows: 276 Leap Indicator (LI): This is a two-bit code warning of an impending 277 leap second to be inserted/deleted in the last minute of the current 278 day, with bit 0 and bit 1, respectively, coded as follows: 280 +------+------------------------------------------------------------+ 281 | LI | Meaning | 282 +------+------------------------------------------------------------+ 283 | 00 | no warning | 284 | 01 | read status command/response | 285 | 10 | read variables command/response | 286 | 11 | write variables command/response | 287 +------+------------------------------------------------------------+ 288 Clock Source (Clock Src): This is a six-bit integer indicating the 289 current synchronization source, with values coded as follows: 291 +-------+-----------------------------------------------------------+ 292 | Code | Meaning | 293 +-------+-----------------------------------------------------------+ 294 | 0 | unspecified or unknown | 295 | 1 | Calibrated atomic clock (e.g.,, HP 5061) | 296 | 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) | 297 | 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) | 298 | 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) | 299 | 5 | local net (e.g.,, DCN,, TSP,, DTS) | 300 | 6 | UDP/NTP | 301 | 7 | UDP/TIME | 302 | 8 | eyeball-and-wristwatch | 303 | 9 | telephone modem (e.g.,, NIST) | 304 | 10-63 | reserved | 305 +-------+-----------------------------------------------------------+ 307 System Event Counter (Count): This is a four-bit integer indicating 308 the number of system exception events occurring since the last time 309 the system status word was returned in a response or included in a 310 trap message. The counter is cleared when returned in the status 311 field of a response and freezes when it reaches the value 15. 313 System Event Code (Code): This is a four-bit integer identifying the 314 latest system exception event, with new values overwriting previous 315 values, and coded as follows: 317 +------+-----------------------------------------------------------+ 318 | Code | Meaning | 319 +------+-----------------------------------------------------------+ 320 | 0 | unspecified | 321 | 1 | system restart | 322 | 2 | system or hardware fault | 323 | 3 | system new status word (leap bits or | 324 | | synchronization change) | 325 | 4 | system new synchronization source or stratum (sys.peer or | 326 | | sys.stratum change) | 327 | 5 | system clock reset (offset correction exceeds CLOCK.MAX) | 328 | 6 | system invalid time or date (see NTP specification) | 329 | 7 | system clock exception (see system clock status word) | 330 | 8-15 | reserved | 331 +------+-----------------------------------------------------------+ 333 3.2. Peer Status Word 335 A peer status word is returned in the status field of a response to a 336 read status, read variables or write variables command and appears 337 also in the list of association identifiers and status words returned 338 by a read status command with a zero association identifier. The 339 format of a peer status word is as follows: 341 Peer Status (Status): This is a five-bit code indicating the status 342 of the peer determined by the packet procedure, with bits assigned as 343 follows: 345 +-------------+---------------------------------------------------+ 346 | Peer Status | Meaning | 347 +-------------+---------------------------------------------------+ 348 | 0 | configured (peer.config) | 349 | 1 | authentication enabled (peer.authenable) | 350 | 2 | authentication okay (peer.authentic) | 351 | 3 | reachability okay (peer.reach ?F255D> 0) | 352 | 4 | reserved | 353 +-------------+---------------------------------------------------+ 355 Peer Selection (SEL): This is a three-bit integer indicating the 356 status of the peer determined by the clock-selection procedure, with 357 values coded as follows: 359 +-----+-------------------------------------------------------------+ 360 | Sel | Meaning | 361 +-----+-------------------------------------------------------------+ 362 | 0 | rejected | 363 | 1 | passed receive sanity checks | 364 | 2 | passed correctness check (intersection algorithm | 365 | 3 | passed candidate checks (if limit check implemented) | 366 | 4 | passed outlyer checks (cluster algorithm | 367 | 5 | current synchronization source; max distance exceeded | 368 | | (if limit check implemented) | 369 | 6 | current synchronization source; max distance okay | 370 | 7 | reserved | 371 +-----+-------------------------------------------------------------+ 373 Peer Event Counter (Count): This is a four-bit integer indicating the 374 number of peer exception events that occurred since the last time the 375 peer status word was returned in a response or included in a trap 376 message. The counter is cleared when returned in the status field of 377 a response and freezes when it reaches the value 15. 379 Peer Event Code (Code): This is a four-bit integer identifying the 380 latest peer exception event, with new values overwriting previous 381 values, and coded as follows: 383 +-------+---------------------------------------------------------+ 384 | Peer | | 385 | Event | Meaning | 386 | Code | | 387 +-------+---------------------------------------------------------+ 388 | 0 | unspecified | 389 | 1 | peer IP error | 390 | 2 | peer authentication failure (peer.authentic bit 1 --> 0 | 391 | 3 | peer unreachable (peer.reach was nonzero now zero) | 392 | 4 | peer reachable (peer.reach was zero now nonzero) | 393 | 5 | peer clock exception (see peer clock status word) | 394 | 6-15 | reserved | 395 +-------+---------------------------------------------------------+ 397 3.3. Clock Status Word 399 There are two ways a reference clock can be attached to a NTP service 400 host, as an dedicated device managed by the operating system and as a 401 synthetic peer managed by NTP. As in the read status command, the 402 association identifier is used to identify which one, zero for the 403 system clock and nonzero for a peer clock. Only one system clock is 404 supported by the protocol, although many peer clocks can be 405 supported. A system or peer clock status word appears in the status 406 field of the response to a read clock variables or write clock 407 variables command. This word can be considered an extension of the 408 system status word or the peer status word as appropriate. The 409 format of the clock status word is as follows: 411 Clock Status: This is an eight-bit integer indicating the current 412 clock status, with values coded as follows: 414 +--------------+--------------------------------------------------+ 415 | Clock Status | Meaning | 416 +--------------+--------------------------------------------------+ 417 | 0 | clock operating within nominals | 418 | 1 | reply timeout | 419 | 2 | bad reply format | 420 | 3 | hardware or software fault | 421 | 4 | propagation failure | 422 | 5 | bad date format or value | 423 | 6 | bad time format or value | 424 | 7-255 | reserved | 425 +--------------+--------------------------------------------------+ 427 Clock Event Code (Code): This is an eight-bit integer identifying the 428 latest clock exception event, with new values overwriting previous 429 values. When a change to any nonzero value occurs in the radio 430 status field, the radio status field is copied to the clock event 431 code field and a system or peer clock exception event is declared as 432 appropriate. 434 3.4. Error Status Word 436 An error status word is returned in the status field of an error 437 response as the result of invalid message format or contents. Its 438 presence is indicated when the E (error) bit is set along with the 439 response (R) bit in the response. It consists of an eight-bit 440 integer coded as follows: 442 +--------------+--------------------------------------------------+ 443 | Error Status | Meaning | 444 +--------------+--------------------------------------------------+ 445 | 0 | unspecified | 446 | 1 | authentication failure | 447 | 2 | invalid message length or format | 448 | 3 | invalid opcode | 449 | 4 | unknown association identifier | 450 | 5 | unknown variable name | 451 | 6 | invalid variable value | 452 | 7 | administratively prohibited | 453 | 8-255 | reserved | 454 +--------------+--------------------------------------------------+ 456 4. Commands 458 Commands consist of the header and optional data field shown in 459 Figure 2. When present, the data field contains a list of 460 identifiers or assignments in the form 461 <>[=<>],<>[=<>],... where 462 <> is the ASCII name of a system or peer variable 463 specified in RFC 5905 and <> is expressed as a decimal, 464 hexadecimal or string constant in the syntax of the C programming 465 language. Where no ambiguity exists, the <169>sys.<170> or 466 <169>peer.<170> prefixes can be suppressed. Whitespace (ASCII 467 nonprinting format effectors) can be added to improve readability for 468 simple monitoring programs that do not reformat the data field. 469 Internet addresses are represented as four octets in the form 470 [n.n.n.n], where n is in decimal notation and the brackets are 471 optional. Timestamps, including reference, originate, receive and 472 transmit values, as well as the logical clock, are represented in 473 units of seconds and fractions, preferably in hexadecimal notation, 474 while delay, offset, dispersion and distance values are represented 475 in units of milliseconds and fractions, preferably in decimal 476 notation. All other values are represented as-is, preferably in 477 decimal notation. 479 Implementations may define variables other than those described in 480 RFC 5905. Called extramural variables, these are distinguished by 481 the inclusion of some character type other than alphanumeric or 482 <169>.<170> in the name. For those commands that return a list of 483 assignments in the response data field, if the command data field is 484 empty, it is expected that all available variables defined in RFC 485 5905 will be included in the response. For the read commands, if the 486 command data field is nonempty, an implementation may choose to 487 process this field to individually select which variables are to be 488 returned. 490 Commands are interpreted as follows: 492 Read Status (1): The command data field is empty or contains a list 493 of identifiers separated by commas. The command operates in two ways 494 depending on the value of the association identifier. If this 495 identifier is nonzero, the response includes the peer identifier and 496 status word. Optionally, the response data field may contain other 497 information, such as described in the Read Variables command. If the 498 association identifier is zero, the response includes the system 499 identifier (0) and status word, while the data field contains a list 500 of binary-coded pairs <> <>, one 501 for each currently defined association. 503 Read Variables (2): The command data field is empty or contains a 504 list of identifiers separated by commas. If the association 505 identifier is nonzero, the response includes the requested peer 506 identifier and status word, while the data field contains a list of 507 peer variables and values as described above. If the association 508 identifier is zero, the data field contains a list of system 509 variables and values. If a peer has been selected as the 510 synchronization source, the response includes the peer identifier and 511 status word; otherwise, the response includes the system identifier 512 (0) and status word. 514 Write Variables (3): The command data field contains a list of 515 assignments as described above. The variables are updated as 516 indicated. The response is as described for the Read Variables 517 command. 519 Read Clock Variables (4): The command data field is empty or contains 520 a list of identifiers separated by commas. The association 521 identifier selects the system clock variables or peer clock variables 522 in the same way as in the Read Variables command. The response 523 includes the requested clock identifier and status word and the data 524 field contains a list of clock variables and values, including the 525 last timecode message received from the clock. 527 Write Clock Variables (5): The command data field contains a list of 528 assignments as described above. The clock variables are updated as 529 indicated. The response is as described for the Read Clock Variables 530 command. 532 Set Trap Address/Port (6): The command association identifier, status 533 and data fields are ignored. The address and port number for 534 subsequent trap messages are taken from the source address and port 535 of the control message itself. The initial trap counter for trap 536 response messages is taken from the sequence field of the command. 537 The response association identifier, status and data fields are not 538 significant. Implementations should include sanity timeouts which 539 prevent trap transmissions if the monitoring program does not renew 540 this information after a lengthy interval. 542 Trap Response (7): This message is sent when a system, peer or clock 543 exception event occurs. The opcode field is 7 and the R bit is set. 544 The trap counter is incremented by one for each trap sent and the 545 sequence field set to that value. The trap message is sent using the 546 IP address and port fields established by the set trap address/port 547 command. If a system trap the association identifier field is set to 548 zero and the status field contains the system status word. If a peer 549 trap the association identifier field is set to that peer and the 550 status field contains the peer status word. Optional ASCII-coded 551 information can be included in the data field. 553 5. IANA Considerations 555 This document makes no request of IANA. 557 Note to RFC Editor: this section may be removed on publication as an 558 RFC. 560 6. Security Considerations 562 A number of security vulnerabilities have been identified with these 563 control messages. 565 NTP's control query interface allows reading and writing of system, 566 peer, and clock variables remotely from arbitrary IP addresses using 567 commands mentioned in Section 4. Traditionally, overwriting these 568 variables, but not reading them, requires authentication by default. 569 However, this document argues that an NTP host must authenticate all 570 control queries and not just ones that overwrite these variables. 572 Alternatively, the host can use a whitelist to explicitly list IP 573 addresses that are allowed to control query the clients. These 574 access controls are required for the following reasons: 576 o NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing 577 query and response packets (modes 1-2, 3-4, 5) are usually short 578 in size. However, some NTP control queries generate a very long 579 packet in response to a short query. As such, there is a history 580 of use of NTP's control queries, which exhibit such behavior, to 581 perform DDoS attacks. These off-path attacks exploit the large 582 size of NTP control queries to cause UDP-based amplification 583 attacks (e.g., mode 7 monlist command generates a very long packet 584 in response to a small query (CVE-2013-5211)). These attacks only 585 use NTP as a vector for DoS atacks on other protocols, but do not 586 affect the time service on the NTP host itself. 588 o Time-shifting attacks through information leakage/overwriting. 589 NTP hosts save important system and peer state variables. An off- 590 path attacker who can read these variables remotely can leverage 591 the information leaked by these control queries to perform time- 592 shifting and DoS attacks on NTP clients. These attacks do affect 593 time synchronization on the NTP hosts. For instance, 595 * In the client/server mode, the client stores its local time 596 when it sends the query to the server in its xmt peer variable. 597 This variable is used to perform TEST2 to non-cryptographically 598 authenticate the server, i.e., if the origin timestamp field in 599 the corresponding server response packet matches the xmt peer 600 variable, then the client accepts the packet. An off-path 601 attacker, with the ability to read this variable can easily 602 spoof server response packets for the client, which will pass 603 TEST2, and can deny service or shift time on the NTP client. 604 CVE-2015-8139 describes the specific attack. 606 * The client also stores its local time when the server response 607 is received in its rec peer variable. This variable is used 608 for authentication in interleaved-pivot mode. An off-path 609 attacker with the ability to read this state variable can 610 easily shift time on the client by passing this test. CVE- 611 2016-1548 describes the attack. 613 o Fast-Scanning. NTP mode 6 control messages are usually small UDP 614 packets. Fast-scanning tools like ZMap can be used to spray the 615 entire (potentially reachable) Internet with these messages within 616 hours to identify vulnerable hosts. To make things worse, these 617 attacks can be extremely low-rate, only requiring a control query 618 for reconnaissance and a spoofed response to shift time on 619 vulnerable clients. CVE-2016-1548 is one such example. 621 NTP best practices recommend configuring ntpd with the no-query 622 parameter. The no-query parameter blocks access to all remote 623 control queries. However, sometimes the nosts do not want to block 624 all queries and want to give access for certain control queries 625 remotely. This could be for the purpose of remote management and 626 configuration of the hosts in certain scenarios. Such hosts tend to 627 use firewalls or other middleboxes to blacklist certain queries 628 within the network. 630 Recent work (reference needed) shows that significantly fewer hosts 631 respond to mode 7 monlist queries as compared to other control 632 queries because it is a well-known and exploited control query. 633 These queries are likely blocked using blacklists on firewalls and 634 middleboxes rather than the no-query option on NTP hosts. The 635 remaining control queries that can be exploited likely remain out of 636 the blacklist because they are undocumented in the current NTP 637 specification [RFC5905]. 639 This document describes all of the mode 6 control queries allowed by 640 NTP and can help administrators make informed decisions on security 641 measures to protect NTP devices from harmful queries and likely make 642 those systems less vulnerable. 644 7. Acknowledgements 646 Tim Plunkett created the original version of this document. Aanchal 647 Malhotra provided the initial version of the Security Considerations 648 section. 650 8. Normative References 652 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 653 Specification, Implementation and Analysis", RFC 1305, 654 DOI 10.17487/RFC1305, March 1992, 655 . 657 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 658 "Network Time Protocol Version 4: Protocol and Algorithms 659 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 660 . 662 Authors' Addresses 664 Dr. David L. Mills 665 University of Deleware 667 Email: mills@udel.edu 668 Brian Haberman (editor) 669 JHU 671 Email: brian@innovationslab.net