idnits 2.17.1 draft-ietf-ntp-ntpv4-proto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1294. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1107: '... 1. A client MUST NOT use a poll int...' RFC 2119 keyword, line 1109: '... 2. A client SHOULD increase the pol...' RFC 2119 keyword, line 1113: '... 3. A client SHOULD use local server...' RFC 2119 keyword, line 1116: '... 4. A client MUST allow the operator...' RFC 2119 keyword, line 1120: '...r IP address is provided, it MUST be a...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 660 has weird spacing: '...ptional opt...' == Line 780 has weird spacing: '...ntifier igno...' == Line 782 has weird spacing: '...mestamp ign...' == Line 783 has weird spacing: '... update sour...' == Line 785 has weird spacing: '...mestamp ign...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FUR94' is mentioned on line 153, but not defined ** Obsolete normative reference: RFC 1305 (ref. 'MIL92') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (ref. 'MIL96') (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'DER98') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 958 (ref. 'MIL85') (Obsoleted by RFC 1059, RFC 1119, RFC 1305) -- Obsolete informational reference (is this intentional?): RFC 1059 (ref. 'MIL88') (Obsoleted by RFC 1119, RFC 1305) -- Obsolete informational reference (is this intentional?): RFC 1119 (ref. 'MIL89') (Obsoleted by RFC 1305) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol Working J. Burbank (Editor) 3 Group JHU/APL 4 Internet-Draft J. Martin (co-Editor) 5 Expires: January 9, 2006 Netzwert AG 6 July, 2005 8 The Network Time Protocol Version 4 Protocol Specification 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3978. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she becomes aware will be disclosed, in accordance with 18 Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This document is a submission of the IETF NTP WG. Comments should be 37 directed to the NTP WG mailing list, ntpwg@lists.ntp.isc.org. 39 This Internet-Draft will expire on January 9, 2006. 41 Abstract 43 The Network Time Protocol (NTP) is widely used to synchronize 44 computer clocks in the Internet. This memorandum describes 45 Version 4 of the NTP (NTPv4), introducing several changes from 46 Version 3 of NTP (NTPv3) described in RFC 1305, including the 47 introduction of a modified protocol header to accomodate Internet 48 Protocol Version 6. NTPv4 also includes optional extensions to the 49 NTPv3 protocol,including an anycast mode and an authentication scheme 50 designed specifically for multicast and anycast modes. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. NTPv4 Protocol Operation . . . . . . . . . . . . . . . . . . . 4 58 3. NTPv4 Timestamp Format . . . . . . . . . . . . . . . . . . . . 6 60 4. NTPv4 Message Formats . . . . . . . . . . . . . . . . . . . . 7 62 5. NTPv4 Client Operations . . . . . . . . . . . . . . . . . . . 13 64 6. NTPv4 Server Operations . . . . . . . . . . . . . . . . . . . 15 66 7. NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . . . 19 67 7.1 Session Keys and Cookies . . . . . . . . . . . . . . . . . 19 68 7.2 Session Key List Generation . . . . . . . . . . . . . . . 20 69 7.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . 20 70 7.4 Receiving Messages . . . . . . . . . . . . . . . . . . . . 20 71 7.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 20 73 8. Operation and Management Issues . . . . . . . . . . . . . . . 22 75 9. Kiss o' Death Message . . . . . . . . . . . . . . . . . . . . 22 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 12. Other Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 14.1 Normative References . . . . . . . . . . . . . . . . . . 27 87 14.2 Informative References . . . . . . . . . . . . . . . . . 27 88 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 90 Intellectual Property and Copyright Statements . . . . . . . . 29 92 1. Introduction 94 The Network Time Protocol Version 3 (NTPv3) specified in RFC 1305 95 [MIL92] has been widely used to synchronize computer clocks in the 96 global Internet. It provides comprehensive mechanisms to access 97 national time and frequency dissemination services, organize the NTP 98 subnet of servers and clients and adjust the system clock in each 99 participant. In most places of the Internet of today, NTP provides 100 accuracies of 1-50 ms, depending on the characteristics of the 101 synchronization source and network paths. 103 NTP is designed for use by clients and servers with a wide range of 104 capabilities and over a wide range of network jitter and clock 105 frequency wander characteristics. Many users of NTP in the Internet 106 of today use a software distribution available from www.ntp.org. The 107 distribution, which includes the full suite of NTP options, 108 mitigation algorithms and security schemes, is a relatively complex, 109 real-time application. While the software has been ported to a wide 110 variety of hardware platforms ranging from personal computers to 111 supercomputers, its sheer size and complexity is not appropriate for 112 many applications. This facilitated the development of the Simple 113 Network Time Protocol Version 4 (SNTPv4) as described in RFC 2030 114 [MIL96]. 116 Since the standardization of NTPv3, there has been significant 117 development which has led to Version 4 of the Network Time Protocol 118 (NTPv4). This document describes NTPv4, which introduces new 119 functionality to NTPv3 as described in RFC 1305, and functionality 120 expanded from that of SNTPv4 as described in RFC 2030 (SNTPv4 is a 121 subset of NTPv4). 123 When operating with current and previous versions of NTP and SNTP, 124 NTPv4 requires no changes to the protocol or implementations now 125 running or likely to be implemented specifically for future NTP or 126 SNTP versions. The NTP and SNTP packet formats are the same and the 127 arithmetic operations to calculate the client time, clock offset and 128 roundtrip delay are the same. To a NTP or SNTP server, NTP and SNTP 129 clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP 130 servers are indistinguishable. 132 An important provision in this memo is the interpretation of certain 133 NTP header fields which provide for IPv6 and OSI addressing. The 134 only significant difference between the NTPv3 and NTPv4 header 135 formats is the four-octet Reference Identifier field, which is used 136 primarily to detect and avoid synchronization loops. In all NTP and 137 SNTP versions providing IPv4 addressing, primary servers use a four- 138 character ASCII reference clock identifier in this field, while 139 secondary servers use the 32-bit IPv4 address of the synchronization 140 source. In NTPv4 providing IPv6 and OSI addressing, primary 141 servers use the same clock identifier, but secondary servers use the 142 first 32 bits of the MD5 hash of the IPv6 or NSAP address of the 143 synchronization source. A further use of this field is when the 144 server sends a kiss-o'-death message documented later in this 145 document. 147 In the case of OSI, the Connectionless Transport Service (CLTS) is 148 used as in [ISO86]. Each NTP packet is transmitted as the TS- 149 Userdata parameter of a T-UNITDATA Request primitive. Alternately, 150 the header can be encapsulated in a TPDU which itself is transported 151 using UDP, as described in RFC-1240 [DOB91]. It is not advised that 152 NTP be operated at the upper layers of the OSI stack, such as might 153 be inferred from RFC-1698 [FUR94], as this could seriously degrade 154 accuracy. With the header formats defined in this memo, it is in 155 principle possible to interwork between servers and clients of one 156 protocol family and another, although the practical difficulties may 157 make this inadvisable. 159 In the following, indented paragraphs such as this one contain 160 information not required by the formal protocol specification, but 161 considered good practice in protocol implementations. 163 This document is organized as follows. Section 2 describes how the 164 protocol works, the various modes and how IP addresses and UDP ports 165 are used. Section 3 describes the NTP timestamp format and Section 4 166 the NTP message format. Section 5 summarizes NTP client operations 167 and Section 6 summarizes NTP server operations. Section 7 summarizes 168 the optional security mechanisms present within the NTPv4 protocol. 169 Section 8 summarizes operation and management issues. Section 9 170 describes the kiss-o'-death message, whose functionality is 171 similar to the ICMP Source Quench and ICMP Destination Unreachable 172 messages. Section 10 presents NTPv4 security considerations. 173 Section 11 presents various other considerations when implementing 174 and/or configuring NTPv4. 176 NTPv4 is hereafter referred to simply as NTP, unless explicitly 177 noted. 179 2. NTP Protocol Operation 181 Unless excepted in context, reference to broadcast address means IPv4 182 broadcast address, IPv4 multicast group address or IPv6 site-local 183 scope address. Further information on the broadcast/multicast model 184 is in RFC 1112 [DEE89]. Details of address format, scoping rules, 185 etc., are beyond the scope of this memo. NTPv4 can operate with 186 either unicast (point to point), broadcast (point to multipoint) or 187 anycast (multipoint to point) addressing modes. A unicast client 188 sends a request to a designated server at its unicast address and 189 expects a reply from which it can determine the time and, optionally, 190 the roundtrip delay and clock offset relative to the server. A 191 broadcast server periodically sends an unsolicited message to a 192 designated broadcast address. A broadcast client listens on this 193 address and ordinarily sends no requests. 195 Anycast is designed for use with a set of cooperating servers whose 196 addresses are not known beforehand. The anycast client sends an 197 ordinary NTP client request to a designated broadcast address. One 198 or more anycast servers listen on that address. Upon receiving a 199 request, an anycast server sends an ordinary NTP server reply to the 200 client. The client then binds to the server from which the first 201 such message was received and continues operation with that unicast 202 addresses. Subsequent replies from other anycast servers are 203 ignored. 205 Broadcast servers should respond to client unicast requests, as 206 well as send unsolicited broadcast messages. Broadcast clients 207 may send unicast requests in order to measure the network 208 propagation delay between the server and client and then continue 209 operation in listen-only mode. However, broadcast servers may 210 choose not to respond to unicast requests, so unicast clients 211 should be prepared to abandon the measurement and assume a default 212 value for the delay. 214 The client and server addresses are assigned following the usual 215 IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has 216 reserved the IPv4 group address 224.0.1.1 and the IPv6 group address 217 ending :101, with prefix determined by scoping rules. The NTP 218 broadcast address for OSI has yet to be determined. Notwithstanding 219 the IANA reserved addresses, other multicast addresses can be used 220 which do not conflict with others assigned in scope. In the case of 221 IPv4 multicast or IPv6 broadcast addresses, the client must implement 222 the Internet Group Management Protocol (IGMP) as described in RFC- 223 3376 [CAIN02], in order that the local router joins the multicast 224 group and relays messages to the IPv4 or IPv6 multicast group. The 225 scoping, routing and group membership procedures are determined by 226 considerations beyond the scope of this memo. 228 It is important to adjust the time-to-live (TTL) field in the IP 229 header of multicast messages to a reasonable value in order to 230 limit the network resources used by this (and any other) multicast 231 service. Only multicast clients in scope will receive multicast 232 server messages. Only cooperating anycast servers in scope will 233 reply to a client request. The engineering principles which 234 determine the proper values to be used are beyond the scope of 235 this memo. 237 While not integral to the NTP specification, it is intended that 238 IP broadcast addresses will be used primarily in IP subnets and 239 LAN segments including a fully functional NTP server with a number 240 of dependent NTP broadcast clients on the same subnet, while IP 241 multicast group addresses will be used only in cases where the TTL 242 is engineered specifically for each service domain. 244 3. NTP Timestamp 246 NTPv4 uses the standard NTP timestamp format described in RFC-1305. 247 NTP data are specified as integer or fixed-point quantities, with 248 bits numbered in big-endian fashion from 0 starting at the left or 249 most significant end. Unless specified otherwise, all quantities 250 are unsigned and may occupy the full field width with an implied 0 251 preceding bit 0. 253 NTP timestamps are represented as a 64-bit unsigned fixed-point 254 number, in seconds relative to 0h on 1 January 1900. The integer 255 part is in the first 32 bits and the fraction part in the 256 last 32 bits. In the fraction part, the non-significant low order 257 bits are not specified and ordinarily set to 0. The NTP timestamp 258 format is as shown in Figure 1. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Seconds | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Fraction | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 1. NTP Timestamp Format 270 It is advisable to fill the non-significant low order bits of the 271 timestamp with a random, unbiased bitstring, both to avoid 272 systematic roundoff errors and as a means of loop detection and 273 replay detection (see below). It is important that the bitstring 274 be unpredictable by a intruder. One way of doing this is to 275 generate a random 128-bit bitstring at startup. After that, each 276 time the system clock is read the string consisting of the 277 timestamp and bitstring is hashed with the MD5 algorithm, then the 278 non-significant bits of the timestamp are copied from the result. 280 The NTP format allows convenient multiple-precision arithmetic and 281 conversion to UDP/TIME message (seconds), but does complicate the 282 conversion to ICMP Timestamp message (milliseconds) and Unix time 283 values (seconds and microseconds or seconds and nanoseconds). The 284 maximum number that can be represented is 4,294,967,295 seconds with 285 a precision of about 232 picoseconds, which should be adequate for 286 even the most exotic requirements. 288 Note that, since some time in 1968 (second 2,147,483,648) the most 289 significant bit (bit 0 of the integer part) has been set and that the 290 64-bit field will overflow some time in 2036 (second 4,294,967,296). 291 There will exist a 232-picosecond interval, henceforth ignored, every 292 136 years when the 64-bit field will be 0, which by convention is 293 interpreted as an invalid or unavailable timestamp. 295 If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time 296 is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not 297 set, the time is in the range 2036-2104 and UTC time is reckoned from 298 6h 28m 16s UTC on 7 February 2036. Note that when calculating the 299 correspondence, 2000 is a leap year and leap seconds are not included 300 in the reckoning. 302 4. NTP Message Formats 304 Both NTP and SNTP are clients of the User Datagram Protocol (UDP) 305 [POS80], which itself is a client of the Internet Protocol (IP) 306 [DAR81] [DER98]. The structure of the IP and UDP headers is described 307 in the cited specification documents and will not be detailed further 308 here. The UDP port number assigned to NTP is 123, which should be 309 used in both the Source Port and Destination Port fields in the UDP 310 header. The remaining UDP header fields should be set as described in 311 the specification. 313 Below is a description of the NTPv4 message format, which follows 314 the IP and UDP headers. This format is identical to that described in 315 RFC 1305, with the exception of the contents of the reference 316 identifier field. The header fields are defined in Figure 2. 318 Leap Indicator (LI): 319 This is a two-bit field indicating an impending leap second to be 320 inserted in the NTP timescale. The bits are set before 23:59 on 321 the day of insertion and reset after 00:00 on the following day. 322 This causes the number of seconds (rollover interval) in the day 323 of insertion to be increased or decreased by one. In the case of 324 primary servers the bits are set by operator intervention, while 325 in the case of secondary servers the bits are set by the protocol. 326 The possible values of the LI field, and corresponding meanings, 327 are as follows: 329 LI Meaning 330 --------------------------------------------- 331 0 no warning 332 1 last minute has 61 seconds 333 2 last minute has 59 seconds) 334 3 alarm condition (clock not synchronized) 336 On startup, servers set this field to 3 (clock not synchronized) 337 and set this field to some other value when synchronized to the 338 primary reference clock. Once set to other than 3, the field is 339 never set to that value again, even if all synchronization sources 340 become unreachable or defective. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |LI | VN |Mode | Strat | Poll | Prec | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Root Delay | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Root Dispersion | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reference ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 + Reference Timestamp + 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 + Origin Timestamp + 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 + Receive Timestamp + 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 + Transmit Timestamp + 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 + Extension Field 1 (Optional) + 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 + Extension Field 2 (Optional) + 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 . . 378 . Authentication . 379 . (Optional) (160 bits) . 380 . . 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 2 NTP Message Format 385 Version (VN): 386 This is a three-bit integer indicating the NTP/SNTP version 387 number, currently 4. If necessary to distinguish between IPv4, 388 IPv6 and OSI, the encapsulating context must be inspected. 390 Mode: 391 This is a three-bit number indicating the protocol mode. The 392 values are defined as follows: 394 Mode Meaning 395 ------------------------------------ 396 0 reserved 397 1 symmetric active 398 2 symmetric passive 399 3 client 400 4 server 401 5 broadcast 402 6 reserved for NTP control message 403 7 reserved for private use 405 In unicast and anycast modes, the client sets this field to 3 406 (client) in the request and the server sets it to 4 (server) in 407 the reply. In broadcast mode, the server sets this field to 5 408 (broadcast). 410 Stratum (Strat): 411 This is a eight-bit unsigned integer indicating the stratum. 412 This field is significant only in SNTP server messages, where the 413 values are defined as follows: 415 Stratum Meaning 416 ---------------------------------------------- 417 0 kiss-o'-death message 418 1 primary reference (e.g., synchronized by radio clock) 419 2-15 secondary reference (synchronized by NTP or SNTP) 420 16-255 reserved 422 Poll Interval (Poll): 423 This is an eight-bit unsigned integer used as an exponent of two, 424 where the resulting value is the maximum interval between 425 successive messages in seconds. This field is significant only in 426 SNTP server messages, where the values range from 4 (16 s) to 17 427 (131,072 s - about 36 h). 429 Precision (Prec): 430 This is an eight-bit signed integer used as an exponent of 431 two, where the resulting value is the precision of the system 432 clock in seconds. This field is significant only in server 433 messages, where the values range from -6 for mains-frequency 434 clocks to -20 for microsecond clocks found in some workstations. 436 Root Delay: 437 This is a 32-bit signed fixed-point number indicating the 438 total roundtrip delay to the primary reference source, in seconds 439 with fraction point between bits 15 and 16. Note that this 440 variable can take on both positive and negative values, depending 441 on the relative time and frequency offsets. This field is 442 significant only in server messages, where the values range from 443 negative values of a few milliseconds to positive values of 444 several hundred milliseconds. 446 Root Dispersion: 447 This is a 32-bit unsigned fixed-point number indicating the 448 nominal error relative to the primary reference source, in seconds 449 with fraction point between bits 15 and 16. This field is 450 significant only in server messages, where the values range from 451 zero to several hundred milliseconds. 453 Reference Identifier: 454 This is a 32-bit bitstring identifying the particular reference 455 source. This field is significant only in server messages, where 456 for stratum 0 (kiss-o'-death message) and 1 (primary server), the 457 value is a four-character ASCII string, left justified and zero 458 padded to 32 bits. For IPv4 secondary servers,the value is the 459 32-bit IPv4 address of the synchronization source. For IPv6 and 460 OSI secondary servers, the value is the first 32 bits of the MD5 461 hash of the IPv6 or NSAP address of the synchronization source. 463 Primary (stratum 1) servers set this field to a code identifying 464 the external reference source according to the below table. 466 Code External Reference Source 467 ---------------------------------------------------------------- 468 LOCL uncalibrated local clock 469 CESM calibrated Cesium clock 470 RBDM calibrated Rubidium clock 471 PPS calibrated quartz clock or other pulse-per-second 472 source 473 IRIG Inter-Range Instrumentation Group 474 ACTS NIST telephone modem service 475 USNO USNO telephone modem service 476 PTB PTB (Germany) telephone modem service 477 TDF Allouis (France) Radio 164 kHz 478 DCF Mainflingen (Germany) Radio 77.5 kHz 479 MSF Rugby (UK) Radio 60 kHz 480 WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz 481 WWVB Boulder (US) Radio 60 kHz 482 WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz 483 CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz 484 LORC LORAN-C radionavigation system 485 OMEG OMEGA radionavigation system 486 GPS Global Positioning Service 488 If the external reference is one of those listed, the associated 489 code should be used. Codes for sources not listed can be contrived 490 as appropriate. 492 In previous NTP and SNTP secondary servers and clients this field 493 was often used to walk-back the synchronization subnet to the root 494 (primary server) for management purposes. 496 Reference Timestamp: 497 This field is significant only in server messages, where the value 498 is the time at which the system clock was last set or corrected, 499 in 64-bit timestamp format. 501 Originate Timestamp: 502 This is the time at which the request departed the client for the 503 server, in 64-bit timestamp format. 505 Receive Timestamp: 506 This is the time at which the request arrived at the server or the 507 reply arrived at the client, in 64-bit timestamp format. 509 Transmit Timestamp: 510 This is the time at which the request departed the client or the 511 reply departed the server, in 64-bit timestamp format. 513 NTPv4 Extension Fields: 514 NTPv4 defines new extension field formats. These fields are 515 processed in order and may be transmitted with or without value 516 fields. The last field is padded to a 64-bit boundary, all others 517 fields are padded to 32-bit boundaries. The field length is for 518 all payload and padding. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Field Type | Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Association ID | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Timestamp | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Filestamp | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Value Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 . . 534 . Value . 535 . . 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Signature Length | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 . . 540 . Signature . 541 . . 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Padding (as needed) | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 3 NTPv4 Extension Field 548 Authentication (optional): 549 The authentication field format is shown in Figure 4. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Key Identifier | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 + + 558 | | 559 + Message Digest + 560 | | 561 + + 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 4 Optional Authentication Field 567 When the NTP authentication scheme is implemented, the 16-bit Key 568 Identifier and 128-bit Message Digest fields contain the Message 569 Authentication Code (MAC) information which uses an MD5 cryptosum 570 of NTP header plus extension fields. 572 5. NTP Client Operations 574 An NTP client can operate in unicast, broadcast or anycast modes. In 575 unicast mode the client sends a request (NTP mode 3) to a designated 576 unicast server and expects a reply (NTP mode 4) from that server. In 577 broadcast client mode it sends no request and waits for a broadcast 578 (NTP mode 5) from one or more broadcast servers. In anycast mode, 579 the client sends a request (NTP mode 3) to a designated broadcast 580 address and expects a reply (NTP mode 4) from one or more anycast 581 servers. The client uses the first reply received to establish the 582 particular server for subsequent unicast operations. Later replies 583 from this server (duplicates) or any other server are ignored. Other 584 than the selection of address in the request, the operations of 585 anycast and unicast clients are identical. 587 Client requests are normally sent at intervals depending on the 588 frequency tolerance of the client clock and the required accuracy. 589 However, under no conditions should requests be sent at less than 590 one minute intervals. Further discussion on this point is in 591 Section 9. 593 A unicast or anycast client initializes the NTP message header, sends 594 the request to the server and strips the time of day from the 595 Transmit Timestamp field of the reply. For this purpose, all of the 596 NTP header fields shown above are set to 0, except the Mode, VN and 597 optional Transmit Timestamp fields. 599 NTP and SNTP clients set the mode field to 3 (client) for unicast and 600 anycast requests. They set the VN field to any version number 601 supported by the server selected by configuration or discovery and 602 can interoperate with all previous version NTP and SNTP servers. 603 Servers reply with the same version as the request, so the VN field 604 of the request also specifies the VN field of the reply. An NTP 605 client can specify the earliest acceptable version on the expectation 606 that any server of that or later version will respond. NTPv4 servers 607 are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 608 as defined in RFC 1119 [MIL89], and NTPv1 as defined in RFC 1059 609 [MIL88]. NTPv0 defined in RFC 959 [MIL85] is not supported. 611 In unicast and anycast modes, the Transmit Timestamp field in the 612 request should be set to the time of day according to the client 613 clock in NTP timestamp format. This allows a simple calculation to 614 determine the propagation delay between the server and client and to 615 align the system clock generally within a few tens of milliseconds 616 relative to the server. In addition, this provides a simple method 617 to verify that the server reply is in fact a legitimate response to 618 the specific client request and avoid replays. In broadcast mode, 619 the client has no information to calculate the propagation delay or 620 determine the validity of the server, unless one of the NTP 621 authentication schemes is used. The following table summarizes the 622 required NTP client operations in unicast, anycast and broadcast 623 modes. The recommended error checks are shown in the Reply and 624 Broadcast columns in the table. The message should be considered 625 valid only if all the fields shown contain values in the respective 626 ranges. Whether to believe the message if one or more of the fields 627 marked "ignore" contain invalid values is at the discretion of the 628 implementation. 630 Field Name Unicast/Anycast Broadcast 631 Request Reply 632 --------------------------------------------------------------- 633 LI 0 0-3 0-3 635 VN 1-4 copied from 1-4 636 request 638 Mode 1 or 3 2 or 4 5 640 Stratum 0 0-15 0-15 642 Poll 0 ignore ignore 644 Precision 0 ignore ignore 646 Root Delay 0 ignore ignore 648 Root Dispersion 0 ignore ignore 650 Reference Identifier 0 ignore ignore 652 Reference Timestamp 0 ignore ignore 654 Originate Timestamp 0 (see text) ignore 656 Receive Timestamp 0 (see text) ignore 658 Transmit Timestamp (see text) nonzero nonzero 660 Authenticator optional optional optional 662 [Need to add a similar table for symmetric modes of operation] 664 6. NTP Server Operations 666 An NTP server operating with either an NTP or SNTP client of the same 667 or previous versions retains no persistent state. Since a SNTP 668 server ordinarily does not implement the full suite of grooming and 669 mitigation algorithms intended to support redundant servers and 670 diverse network paths, a SNTP server should be operated only in 671 conjunction with a source of external synchronization, such as a 672 reliable radio clock or telephone modem. In this case it operates as 673 a primary (stratum 1) server. 675 An NTP server can operate with any unicast, anycast or broadcast 676 address or any combination of these addresses. A unicast or anycast 677 server receives a request (NTP mode 3), modifies certain fields in 678 the NTP header, and sends a reply (NTP mode 4), possibly using the 679 same message buffer as the request. A anycast server listens on the 680 designated broadcast address, but uses its own unicast IP address in 681 the source address field of the reply. Other than the selection of 682 address in the reply, the operations of anycast and unicast servers 683 are identical. Broadcast messages are normally sent at poll 684 intervals from 64 s to 1024 s, depending on the expected frequency 685 tolerance of the client clocks and the required accuracy. 687 Unicast and anycast servers copy the VN and Poll fields of the 688 request intact to the reply and set the Stratum field to 1. 690 Note that SNTP servers normally operate as primary (stratum 1) 691 servers. While operating at higher strata (up to 15) and at the 692 same time synchronizing to an external source such as a GPS 693 receiver is not forbidden, this is strongly discouraged. 695 If the Mode field of the request is 3 (client), the reply is set to 4 696 (server). If this field is set to 1 (symmetric active), the reply is 697 set to 2 (symmetric passive). This allows clients configured in 698 either client (NTP mode 3) or symmetric active (NTP mode 1) to 699 interoperate successfully, even if configured in possibly suboptimal 700 ways. For any other value in the Mode field, the request is 701 discarded. In broadcast (unsolicited) mode, the VN field is set to 702 4, the Mode field is set to 5 (broadcast), and the Poll field set to 703 the nearest integer base-2 logarithm of the poll interval. 705 Note that it is highly desirable that a broadcast server also 706 supports unicast clients. This is so a potential broadcast client 707 can calculate the propagation delay using a client/server exchange 708 prior to switching to broadcast client (listen-only) mode. A 709 anycast server by design also is a unicast server. There does not 710 seem to be a great advantage for a server to operate as both 711 broadcast and anycast at the same time, although the protocol 712 specification does not forbid it. 714 A broadcast or anycast server may or may not respond if not 715 synchronized to a correctly operating reference source, but the 716 preferred option is to respond, since this allows reachability to be 717 determined regardless of synchronization state. If the server has 718 never synchronized to a reference source, the LI field is set to 3 719 (unsynchronized). Once synchronized to a reference source, the LI 720 field is set to one of the other three values and remains at the last 721 value set even if the reference source becomes unreachable or turns 722 faulty. 724 If synchronized to a reference source the Stratum field is set to 1 725 and the Reference Identifier field is set to the ASCII source 726 identifier shown in Figure 2. If not synchronized, the Stratum field 727 is set to zero and the Reference Identifier field set to an ASCII 728 error identifier described below. In broadcast mode, the server 729 sends broadcasts only if synchronized to a correctly operating 730 reference source. 732 The Precision field is set to reflect the maximum reading error of 733 the system clock. For all practical cases it is computed as the 734 negative base-2 logarithm of the number of significant bits to the 735 right of the decimal point in the NTP timestamp format. The Root 736 Delay and Root Dispersion fields are set to 0 for a primary server; 737 optionally, the Root Dispersion field can be set to a value 738 corresponding to the maximum expected error of the radio clock 739 itself. 741 The timestamp fields in the server message are set as follows. If 742 the server is unsynchronized or first coming up, all timestamp fields 743 are set to zero with one exception. If the message is a reply to a 744 previously received client request, the Transmit Timestamp field of 745 the request is copied unchanged to the Originate Timestamp field of 746 the reply. It is important that this field be copied intact, as an 747 NTP or SNTP client uses it to avoid bogus messages. 749 If the server is synchronized, the Reference Timestamp is set to the 750 time the last update was received from the reference source. The 751 Originate Timestamp field is set as in the unsynchronized case above. 752 The Transmit Timestamp field are set to the time of day when the 753 message is sent. In broadcast messages the Receive Timestamp field 754 is set to zero and copied from the Transmit Timestamp field in other 755 messages. The following table summarizes these actions. 757 Field Name Unicast/Anycast Broadcast 758 Request Reply 759 ---------------------------------------------------------------- 760 LI ignore as needed as needed 762 VN 1-4 copied from 4 763 request 765 Mode 1 or 3 2 or 4 5 767 Stratum ignore 1 1 769 Poll ignore copied from log2 poll 770 request interval 772 Precision ignore -log2 server -log2 server 773 significant significant 774 bits bits 776 Root Delay ignore 0 0 778 Root Dispersion ignore 0 0 780 Reference Identifier ignore source ident source ident 782 Reference Timestamp ignore time of last time of last 783 source update source update 785 Originate Timestamp ignore copied from 0 786 transmit 787 timestamp 789 Receive Timestamp ignore time of day 0 791 Transmit Timestamp (see text) time of day time of day 793 Authenticator optional optional optional 795 [Need to add a similar table for symmetric modes of operation] 797 There is some latitude on the part of most clients to forgive invalid 798 timestamps, such as might occur when first coming up or during 799 periods when the reference source is inoperative. The most important 800 indicator of an unhealthy server is the Stratum field, in which a 801 value of 0 indicates an unsynchronized condition. When this value is 802 displayed, clients should discard the server message, regardless of 803 the contents of other fields. 805 7. NTPv4 Security 807 NTPv4 employs the Autokey security protocol, which works 808 independently for each client, with tentative outcomes confirmed only 809 after both succeed. Public keys and certificates are obtained and 810 verified relatively infrequently using X.509 certificates and 811 certificate trails. Session keys are derived from public keys. Each 812 NTP message is individually authenticated using the session key and 813 the message digest (keyed MD5). A proventic trail is a sequence of 814 NTP servers each synchronized and cryptographically veritifed to the 815 next lower stratum server and ending on one or more trusted servers. 816 Proventic trails are constructed from each server to the trusted 817 servers at decreasing stratum levels. When server time and at least 818 one proventic trail are verified, the peer is admitted to the 819 population and used to synchronize the system clock. 821 7.1 Session Keys and Cookies 823 NTPv4 session keys have four 32-bit words, as shown in Figure 5. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Source Address | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Destination Address | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Key ID | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Cookie | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Figure 5. NTPv4 Session Key Format 839 The session key value is the 16-octet MD5 message digest of the 840 session key. Key IDs have pseudo-random values and are used only 841 once. A special key ID value of zero is used as a NAK reply. In 842 multicast mode, and in any message including an extension field, the 843 cookie has a public value (zero). In client/server modes, the cookie 844 is a hash of the addresses and a private value. In symmetric modes, 845 the cookie is a random roll. In the event that both peers generate 846 cookies, the agreed-upon cookie is the exclusive-OR of the two 847 values. 849 The server generates a cookie unique to the client and server 850 addresses and its own private value. It returns the cookie, 851 signature, and timestampe to the client in an extension field. The 852 cookie is transmitted from server to client encrypted by the client 853 public key. The server uses the cookie to validate requests and 854 construct replies. The client uses the cookie to validate the reply 855 and checks that the request key ID matches the reply key ID. 857 7.2 Session Key List Generation 859 The server rolls a random 32-bit seed as the initial key ID and 860 selects the cookie. Messages with a zero cookie contain only public 861 values. The initial session key is constructed using the given 862 addressses, cookie and initial key ID. The session key value is 863 stored in the key cache. The next session key is constructed using 864 the first four octets of the session key value as the new key ID. 865 The server continues to generate the full list. The final index 866 number and last key ID are provided in an extension field with 867 signature and timestamp. 869 7.3 Sending Messages 871 The MAC consists of the MD5 message digest of the NTP header and 872 extension fields using the session key ID and value stored in the key 873 cache. The server uses the session key ID list in reverse order and 874 discards each key value after use. An extension field containing the 875 last index number and key ID is included in the first packet 876 transmitted (last on the list). This extension field can be provided 877 upon request at any time. When all entries in the key list are used, 878 a new one is generated. 880 7.4 Receiving Messages 882 The intent is not to hide the message contents. Rather, the goal is 883 to verify its source and that it has not been modified in transit. 884 The MAC message digest is compared with the computed digest of the 885 NTP header and extension fields using the session key ID in the MAC 886 and the key value computed from the addresses, key ID and cookie. If 887 the cookie is zero, the message contains public values. Anybody can 888 validate the message or make a valid message containing any values. 889 If the cookie has been determined by secret means, nobody except the 890 parties to the secret can validate a message or make a valid message. 892 7.5 Autokey Protocol Exchanges 894 There are five types of Autokey protocol exchanges: 896 1. Parameter Exchange (ASSOC message): This message exchanges host 897 names, agrees on digest/signature and identity schemes. This 898 protocol exchange is unsigned. Optionally, host name/address can 899 be verified using reverse-DNS. An initial association request is 900 sent by the client, sending the host name and status word 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Digest/Signature NID | Client | Ident | Host | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Figure 6 Status Word Format 909 If the server digest NID and ID scheme agree, the server responds 910 with an association response message, sending host name and 911 status word. The client, upon agreeing with digest NID and ID 912 scheme, then sends a certificate request. The server responds 913 with an X.509 certificate and signature. The certificate 914 request/response cycle repeats as needed. A primary (Stratum 1) 915 certifcate is explicitly trusted and self-signed. Secondary 916 certificates are signed by the next lower stratum server and 917 validated with its public key. 919 2. Certificate Exchange (CERT message): This exchange is used to 920 obtain and verify certificates on the trail to a trusted root 921 certificate. Certificate exchanges follow the same process as 922 parameter exchanges. 924 3. Identity Exchange (IFF, GW, and MV messages): This exchange is 925 used to verify server identity using an agreed identity scheme 926 (TC, IFF, GQ, MV). This exchange is a challenge-response scheme. 927 The client initiates by sending a challenge request. The server 928 then provides the challenge response. 930 4. Values Exchange (COOKIE and AUTO messages): This exchange is used 931 to obtain and verify the cookie, autokey values, and leapseconds 932 table, depending on the association mode (client-server, 933 broadcast, symmetric). For cookie exchanges, the client sends 934 its public key to the server without signature when not 935 synchronized. Symmetric active peers send its public key and 936 signature to passive peer when synchronized. The server cookie 937 is encrypted from the hash of source/destination addresses, zero 938 key ID, and server private value. A symmetric passive cookie is a 939 random value for every exchange. The server private value is 940 refreshed and protocol restarted once per day. For autokey 941 exchanges, the server generates a key list and signature is 942 calculated to last about one hour. A client sends requests to 943 the server without signature when not synchronized. The server 944 replies with the last index number and key ID on the list. 945 Broadcast servers uses AUTO response for the first message after 946 regenerating the key and ASSOC responses for all other messages. 948 5. Signature Exchange (SIGN message): This exchange requests the 949 server to sign and return a client certificate. The exchange is 950 valid only when the client has synchronized to a proventic source 951 and the server identity has been confirmed. This exchange is 952 used to authenticate clients to servers, with the server acting 953 as de facto certificate authority using an encrypted credential 954 scheme. The client sends a certificate to the server with or 955 without signature. The server extracts the requested data and 956 signs that data with the server private key. The client then 957 verifies the certificate and signature. Subsequently, the client 958 supplies this certificate rather than self-signed certificates, 959 so clients can verify with the server public key. 960 8. Configuration and Management 962 The means used in the configuration and management of NTP servers 963 and clients is the NTP control and monitoring protocol defined in 964 RFC 1305. 966 Unicast clients must be provided with one or more designated server 967 names or IP addresses. If more than one server is provided, one can 968 be used for active operation and one of the others for backup should 969 the active one fail or show an error condition. It is not normally 970 useful to use more than one server at a time, as with millions of 971 NTP-enabled devices expected in the near future, such use could 972 result in unnecessary strain on network and server resources. 974 Broadcast servers and anycast clients must be provided with the TTL 975 and local broadcast or multicast group address. Unicast and anycast 976 servers and broadcast clients may be configured with a list of 977 address-mask pairs for access control, so that only those clients or 978 servers known to be trusted will be accepted. Multicast servers and 979 clients must implement the IGMP protocol and be provided with the 980 local broadcast or multicast group address as well. The 981 configuration data for cryptographic authentication is beyond the 982 scope of this memo. 984 There are several scenarios which provide automatic server discovery 985 and selection for NTP clients with no pre-specified server 986 configuration. For instance a role server with CNAME such as 987 pool.ntp.org returns a randomized list of volunteer secondary server 988 addresses and the client can select one or more as candidates. For 989 an IP subnet or LAN segment including a NTP or SNTP server, NTP 990 clients can be configured as broadcast clients. The same approach 991 can be used with multicast servers and clients. In both cases, 992 provision of an access control list is a good way to insure only 993 trusted sources can be used to set the system clock. 995 In another scenario suitable for an extended network with significant 996 network propagation delays, clients can be configured for anycast 997 addresses, both upon initial startup and after some period when the 998 currently selected unicast source has not been heard. Following the 999 defined protocol, the client binds to the server from which the first 1000 reply is received and continues operation in unicast mode. 1002 9. The Kiss-o'-Death Packet 1004 In the interest of self-preservation, it is important that NTP 1005 servers have a mechanism to supress or otherwise influence the amount 1006 of queries performed by NTP clients. 1008 According to the NTPv3 specification RFC 1305, if the Stratum field 1009 in the NTP header is 1, indicating a primary server, the Reference 1010 Identifier field contains an ASCII string identifying the particular 1011 reference clock type. However, in RFC 1305 nothing is said about the 1012 Reference Identifier field if the Stratum field is 0, which is called 1013 out as "unspecified". However, if the Stratum field is 0, the 1014 Reference Identifier field can be used to convey messages useful for 1015 status reporting and access control. In NTPv4 and SNTPv4, packets of 1016 this kind are called Kiss-o'-Death (KoD) packets and the ASCII 1017 messages they convey are called kiss codes. The KoD packets got 1018 their name because an early use was to tell clients to stop sending 1019 packets that violate server access controls. 1021 The kiss codes can provide useful information for an intelligent 1022 client. These codes are encoded in four-character ASCII strings left 1023 justified and zero filled. The strings are designed for character 1024 displays and log files. A list of the currently-defined kiss codes 1025 is in the following table. 1027 Code Meaning 1028 -------------------------------------------------------------- 1029 ACST The association belongs to a anycast server 1030 AUTH Server authentication failed 1031 AUTO Autokey sequence failed 1032 BCST The association belongs to a broadcast server 1033 CRYP Cryptographic authentication or identification failed 1034 DENY Access denied by remote server 1035 DROP Lost peer in symmetric mode 1036 RSTR Access denied due to local policy 1037 INIT The association has not yet synchronized for the first 1038 time 1039 MCST The association belongs to a manycast server 1040 NKEY No key found. Either the key was never installed or 1041 is not trusted 1042 RATE Rate exceeded. The server has temporarily denied access 1043 because the client exceeded the rate threshold 1044 RMOT Somebody is tinkering with the association from a remote 1045 host running ntpdc. Not to worry unless some rascal has 1046 stolen your keys 1047 STEP A step change in system time has occurred, but the 1048 association has not yet resynchronized 1050 In general, an NTP client should stop sending to a particular server 1051 if that server returns a reply with a Stratum field of 0, regardless 1052 of kiss code, and an alternate server is available. If no alternate 1053 server is available, the client should retransmit using an 1054 exponential-backoff algorithm described in Section 11. 1056 10. Security Considerations 1058 In the case of NTP as specified herein, there is a very real 1059 vulnerability that NTP broadcast clients can be disrupted by 1060 misbehaving or hostile SNTP or NTP broadcast servers elsewhere in 1061 the Internet. It is strongly recommended that access controls 1062 and/or cryptographic authentication means be provided for 1063 additional security in such cases. 1065 While not required in a conforming NTP client implementation, there 1066 are a variety of recommended checks that an NTP client can perform 1067 that are designed to avoid various types of abuse that might happen 1068 as the result of server implementation errors or malicious attack. 1069 These recommended checks are as follows: 1071 1. When the IP source and destination addresses are available for the 1072 client request, they should match the interchanged addresses in 1073 the server reply. 1075 2. When the UDP source and destination ports are available for the 1076 client request, they should match the interchanged ports in the 1077 server reply. 1079 3. The Originate Timestamp in the server reply should match the 1080 Transmit Timestamp used in the client request. 1082 4. The server reply should be discarded if any of the LI, Stratum, or 1083 Transmit Timestamp fields are 0 or the Mode field is not 4 1084 (unicast) or 5 (broadcast). 1086 5. A truly paranoid client can check the Root Delay and Root 1087 Dispersion fields are each greater than or equal to 0 and less 1088 than infinity, where infinity is currently a cozy number like 16 1089 seconds. This check avoids using a server whose synchronization 1090 source has expired for a very long time. 1092 11. IANA Considerations 1094 12. Other Considerations 1096 NTP and SNTP clients can consume considerable network and server 1097 resources if not "good network citizens." There are now consumer 1098 Internet commodity devices numbering in the millions that are 1099 potential customers of public and private NTP and SNTP servers. 1100 Recent experience strongly suggests that device designers pay 1101 particular attention to minimizing resource impacts, especially if 1102 large numbers of these devices are deployed. The most important 1103 design consideration is the interval between client requests, called 1104 the poll interval. It is extremely important that the design use the 1105 maximum poll interval consistent with acceptable accuracy. 1107 1. A client MUST NOT use a poll interval less than TBD minutes. 1109 2. A client SHOULD increase the poll interval using exponential 1110 backoff as performance permits and especially if the server does 1111 not respond within a reasonable time. 1113 3. A client SHOULD use local servers whenever available to avoid 1114 unnecessary traffic on backbone networks. 1116 4. A client MUST allow the operator to configure the primary and/or 1117 alternate server names or addresses in addition to or in place of 1118 a firmware default IP address. 1120 5. If a firmware default server IP address is provided, it MUST be a 1121 server operated by the manufacturer or seller of the device or 1122 another server, but only with the operator's permission. 1124 6. A client SHOULD use the Domain Name System (DNS) to resolve the 1125 server IP addresses, so the operator can do effective load 1126 balancing among a server clique and change IP address binding to 1127 canonical names. 1129 7. A client SHOULD re-resolve the server IP address on a periodic 1130 intervals, but not less than the time-to-live field in the DNS 1131 response. 1133 8. A client SHOULD support the NTP access-refusal mechanism, so that 1134 a server kiss-o'-death reply in response to a client request 1135 causes the client to cease sending requests to that server and to 1136 switch to an alternate, if available. 1138 If the firmware or documentation includes specific server names, the 1139 names should be those the manufacturer or seller operates as a 1140 customer convenience or those for which specific permission has been 1141 obtained from the operator. A DNS request for a generic server name 1142 such as ntp.mytimeserver.com results should result in a random 1143 selection of server IP addresses available for that purpose. Each 1144 time a DNS request is received, a new randomized list is returned. 1145 The client ordinarily uses the first address on the list. 1147 When selecting candidate SNTP or NTP servers, it is imperative to 1148 respect the server operator's conditions of access. Lists of 1149 public servers and their conditions of access are available at 1150 www.ntp.org. A semi-automatic server discovery scheme using DNS 1151 is described at that site. Some ISPs operate public servers, 1152 although finding them via their helpdesks can be difficult. 1154 A well behaved client operates as follows (note that steps 2 - 4 1155 comprise a synchronization loop): 1157 1. Consider the specified frequency tolerance of the system clock 1158 oscillator. Define the required accuracy of the system clock, 1159 then calculate the maximum timeout. For instance, if the 1160 frequency tolerance is 200 parts-per-million (PPM) and the 1161 required accuracy is one minute, the maximum timeout is about 3.5 1162 days. Use the longest maximum timeout possible given the system 1163 constraints to minimize time server aggregate load, but never less 1164 than 15 minutes. 1166 2. When first coming up or after reset, randomize the timeout from 1167 one to five minutes. This is to minimize shock when 3000 PCs are 1168 rebooted at the same time power is restored after a blackout. 1169 Assume at this time the IP address is unknown and the system clock 1170 is unsynchronized. Otherwise use the timeout value as calculated 1171 in previous loop steps. Note that it may be necessary to refrain 1172 from implementing the aforementioned random delay for some classes 1173 of ICSA certification. 1175 3. When the timer reaches zero, if the IP address is not known, send 1176 a DNS query packet; otherwise send a NTP request packet to that 1177 address. If no reply packet has been heard since the last 1178 timeout, double the timeout, but not greater than the maximum 1179 timeout. If primary and secondary time servers have been 1180 configured, alternate queries between the primary and secondary 1181 servers when no successful response has been received. 1183 4. If a DNS reply packet is received, save the IP address and 1184 continue in step 2. If a KoD packet is received remove that time 1185 server from the list, activate the secondary time server and 1186 continue in step 2. If a received packet fails the sanity checks, 1187 drop that packet and also continue in step 2. If a valid NTP 1188 packet is received, update the system clock, set the timeout to 1189 the maximum, and continue to step 2. 1191 13. Acknowledgements 1193 This document has drawn significant material from the document 1194 . As a result, the authors would like 1195 to acknowledge D. Plonka of the University of Wisconsin and J. 1196 Montgomery of Netgear, who were significant contributors to that 1197 draft. 1199 14. References 1201 14.1 Normative References 1203 [MIL92] Mills, D., "Network Time Protocol (Version 3) Specification, 1204 Implementation", RFC 1305, March 1992. 1206 [MIL96] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1207 IPv4, IPv6, and OSI", RFC 2030, October 1996. 1209 14.2 Informative References 1211 [CAIN02] Cain, B., Deering, S., Kouvalas, I., Fenner, B. and A. 1212 Thyagarajan, "Internet Group Management Protocol, Version 1213 3", RFC 3376, Cereva Networks, October 2002. 1215 [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1216 1981. 1218 [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, 1219 RFC 1112, August 1989. 1221 [DER98] Deering, S., Hinden R., "Internet Protocol, Version 6 (IPv6)," 1222 RFC 2460, December 1998. 1224 [DOB91] Dobbins, K, Haggerty, W. and C. Shue, "OSI connectionless 1225 transport services on top of UDP - Version: 1", RFC 1240, 1226 June 1991. 1228 [ISO86] International Standards 8602 - Information Processing 1229 Systems - OSI: Connectionless Transport Protocol 1230 Specification. International Standards Organization, 1231 December 1986. 1233 [MIL85] Mills, D., "Network Time Protocol (NTP)", RFC 958, 1234 September 1985. 1236 [MIL88] Mills, D., "Network Time Protocol (Version 1) Specification 1237 and Implementation", RFC 1059, July 1988. 1239 [MIL89] Mills, D., "Network Time Protocol (Version 2) Specification 1240 and Implementation," RFC 1119, September 1989. 1242 [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1243 1980. 1245 15. Authors' Addresses 1247 Jack L. Burbank (Editor) 1248 The Johns Hopkins University Applied Physics Laboratory (JHU/APL) 1249 11100 Johns Hopkins Road 1250 Laurel, MD 20723 1252 Phone: +1 443-778-7127 1253 EMail: jack.burbank@jhuapl.edu 1255 Jim Martin (co-Editor) 1256 Netzwert AG 1257 An den Treptowers 1 1258 D-12435 Berlin 1260 Phone: +49.30/5 900 800-180 1261 EMail: jim@Netzwert.AG 1263 Dr. David L. Mills 1264 The University of Delaware 1265 Electrical Engineering Department 1266 University of Delaware 1267 Newark, DE 19716 1269 Phone: (302) 831-8247 1270 EMail: mills@udel.edu 1272 Intellectual Property Statement 1274 The IETF takes no position regarding the validity or scope of any 1275 Intellectual Property Rights or other rights that might be claimed to 1276 pertain to the implementation or use of the technology described in 1277 this document or the extent to which any license under such rights 1278 might or might not be available; nor does it represent that it has 1279 made any independent effort to identify any such rights. Information 1280 on the procedures with respect to rights in RFC documents can be 1281 found in BCP 78 and BCP 79. 1283 Copies of IPR disclosures made to the IETF Secretariat and any 1284 assurances of licenses to be made available, or the result of an 1285 attempt made to obtain a general license or permission for the use of 1286 such proprietary rights by implementers or users of this 1287 specification can be obtained from the IETF on-line IPR repository at 1288 http://www.ietf.org/ipr. 1290 The IETF invites any interested party to bring to its attention any 1291 copyrights, patents or patent applications, or other proprietary 1292 rights that may cover technology that may be required to implement 1293 this standard. Please address the information to the IETF at 1294 ietf-ipr@ietf.org. 1296 Disclaimer of Validity 1298 This document and the information contained herein are provided on an 1299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1301 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1302 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1303 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1306 Copyright Statement 1308 Copyright (C) The Internet Society (2005). This document is subject 1309 to the rights, licenses and restrictions contained in BCP 78, and 1310 except as set forth therein, the authors retain all their rights. 1312 Acknowledgment 1314 Funding for the RFC Editor function is currently provided by the 1315 Internet Society.