idnits 2.17.1 draft-ietf-ntp-bcp-10.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 (December 13, 2018) is 1961 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 928 -- Looks like a reference, but probably isn't: '2' on line 931 -- Looks like a reference, but probably isn't: '3' on line 933 -- Looks like a reference, but probably isn't: '4' on line 935 -- Looks like a reference, but probably isn't: '5' on line 938 -- Looks like a reference, but probably isn't: '6' on line 940 -- Looks like a reference, but probably isn't: '7' on line 942 -- Looks like a reference, but probably isn't: '8' on line 944 -- Looks like a reference, but probably isn't: '9' on line 1050 -- Looks like a reference, but probably isn't: '10' on line 1054 == Outdated reference: A later version (-04) exists of draft-ietf-ntp-data-minimization-03 == Outdated reference: A later version (-06) exists of draft-ietf-ntp-mac-05 == Outdated reference: A later version (-11) exists of draft-ietf-ntp-mode-6-cmds-06 == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-14 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Reilly, Ed. 3 Internet-Draft Orolia USA 4 Intended status: Best Current Practice H. Stenn 5 Expires: June 16, 2019 Network Time Foundation 6 D. Sibold 7 PTB 8 December 13, 2018 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-10 13 Abstract 15 The Network Time Protocol (NTP) is one of the oldest protocols on the 16 Internet and has been widely used since its initial publication. 17 This document is a collection of Best Practices for general operation 18 of NTP servers and clients on the Internet. It includes 19 recommendations for stable, accurate and secure operation of NTP 20 infrastructure. This document is targeted at NTP version 4 as 21 described in RFC 5905. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 16, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. General Network Security Best Practices . . . . . . . . . . . 3 60 2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 62 3.1. Keeping NTP up to date . . . . . . . . . . . . . . . . . 4 63 3.2. Use enough time sources . . . . . . . . . . . . . . . . . 4 64 3.3. Use a diversity of Reference Clocks . . . . . . . . . . . 5 65 3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 6 66 3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 68 3.7. Leap Second Handling . . . . . . . . . . . . . . . . . . 8 69 3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9 70 4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10 71 4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10 72 4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11 74 5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 11 75 5.1. Minimizing Information Leakage . . . . . . . . . . . . . 11 76 5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12 77 5.3. Detection of Attacks Through Monitoring . . . . . . . . . 13 78 5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 13 79 5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 14 80 5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 14 81 6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 82 6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 15 83 6.2. Server configuration . . . . . . . . . . . . . . . . . . 15 84 6.2.1. NTP Pool Project Vendor Subdomains . . . . . . . . . 16 85 7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 11.2. Informative References . . . . . . . . . . . . . . . . . 18 92 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 Appendix A. NTP Implementation by the Network Time 94 Foundation . . . . . . . . . . . . . . . . . . . . . 21 95 A.1. Use enough time sources . . . . . . . . . . . . . . . . . 21 96 A.2. NTP Control and Facility Messages . . . . . . . . . . . . 21 97 A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 22 98 A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 22 99 A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 23 100 A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 23 101 A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 NTP version 4 (NTPv4) has been widely used since its publication as 107 [RFC5905]. This documentation is a collection of best practices for 108 the operation of NTP clients and servers. 110 The recommendations in this document are intended to help operators 111 distribute time on their networks more accurately and more securely. 112 It is intended to apply generally to a broad range of networks. Some 113 specific networks may have higher accuracy requirements that require 114 additional techniques beyond what is documented here. 116 Among the best practices covered are recommendations for general 117 network security, time protocol specific security, and NTP server and 118 client configuration. NTP operation in embedded devices is also 119 covered. 121 This document also contains information for protocol implementors who 122 want to develop their own RFC 5905 compliant implementations. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 2. General Network Security Best Practices 134 2.1. BCP 38 136 Many network attacks rely on modifying the IP source address of a 137 packet to point to a different IP address than the computer which 138 originated it. UDP-based protocols such as NTP are generally more 139 susceptible to spoofing attacks then other connection-oriented 140 protocols. NTP control messages can generate a lot of data in 141 response to a small query, which makes it more attractive as a vector 142 for distributed denial-of-service attacks. (NTP Control messages are 143 discussed further in Section 3.4). One documented instance of such 144 an attack can be found here [1], and further discussion in [IMC14] 145 and [NDSS14]. Mitigating source address spoofing attacks should be a 146 priority of anyone administering NTP. 148 BCP 38 [RFC2827] was approved in 2000 to address this. BCP 38 calls 149 for filtering outgoing and incoming traffic to make sure that the 150 source and destination IP addresses are consistent with the expected 151 flow of traffic on each network interface. It is RECOMMENDED that 152 large corporate networks (and ISP's of any size) implement ingress 153 and egress filtering. More information is available at the BCP38 154 Info Web page [BCP38INFO] . 156 3. NTP Configuration Best Practices 158 This section provides Best Practices for NTP configuration and 159 operation. Best Practices that are specific to the NTF 160 implementation are compiled in Appendix A. 162 3.1. Keeping NTP up to date 164 Many network security mechanisms rely on time as part of their 165 operation. If attackers can spoof the time, they may be able to 166 bypass or neutralize other security elements. For example, incorrect 167 time can disrupt the ability to reconcile logfile entries on the 168 affected system with events on other systems. An application which 169 is secure today could be insecure tomorrow once an unknown bug (or a 170 known behavior) is exploited in the right way. Even our definition 171 of what is secure has evolved over the years, so code which was 172 considered secure when it was written may turn out to be insecure 173 after some time. 175 There are multiple versions of the NTP protocol in use, and multiple 176 implementations, on many different platforms. The practices in this 177 document are meant to apply generally to any implementation of 178 [RFC5905]. It is RECOMMENDED that that NTP users select an 179 implementation that is actively maintained. Users should keep up to 180 date on any known attacks on their selected implementation, and 181 deploy updates containing security fixes as soon as practical. 183 3.2. Use enough time sources 185 An NTP implementation that is compliant with [RFC5905] takes the 186 available sources of time and submits this timing data to 187 sophisticated intersection, clustering, and combining algorithms to 188 get the best estimate of the correct time. The description of these 189 algorithms is beyond the scope of this document. Interested readers 190 should read [RFC5905] or the detailed description of NTP in 191 [MILLS2006]. 193 o If there is only 1 source of time, the answer is obvious. It may 194 not be a good source of time, but it's the only source of time 195 that can be considered. Any issue with the time at the source 196 will be passed on to the client. 198 o If there are 2 sources of time and they agree well enough, then 199 the best time can be calculated easily. But if one source fails, 200 then the solution degrades to the single-source solution outlined 201 above. And if the two sources don't agree, then it's impossible 202 to know which one is correct by simply looking at the time. 204 o If there are 3 sources of time, there is more data available to 205 converge on the best calculated time, and this time is more likely 206 to be accurate. And the loss of one of the sources (by becoming 207 unreachable or unusable) can be tolerated. But at that point, the 208 solution degrades to the 2 source solution. 210 o 4 or more sources of time is better, as long as the sources are 211 diverse (Section 3.3). If one of these sources develops a problem 212 there are still at least 3 other time sources. 214 Operators who are concerned with maintaining accurate time SHOULD use 215 at least 4 independent, diverse sources of time. Four sources will 216 provide sufficient backup in case one source goes down. If four 217 sources are not available, operators MAY use fewer sources, subject 218 to the risks outlined above. 220 But even with 4 or more sources of time, systemic problems can 221 happen. For several hours before and after the June 2015 leap 222 second, several operators implemented leap smearing while others did 223 not, and many NTP end nodes could not determine an accurate time 224 source because 2 of their 4 sources of time gave them consistent UTC/ 225 POSIX time, while the other 2 gave them consistent leap-smeared time. 226 See Section 3.7.1 for more information. 228 Operators SHOULD monitor all of the time sources that are in use. If 229 time sources do not generally agree, find out the cause and either 230 correct the problems or stop using defective servers. See 231 Section 3.5 for more information. 233 3.3. Use a diversity of Reference Clocks 235 When using servers with attached hardware reference clocks, it is 236 RECOMMENDED that several different types of reference clocks be used. 237 Having a diversity of sources with independent implementations means 238 that any one issue is less likely to cause a service interruption. 240 Are all clocks on a network from the same vendor? They may have the 241 same bugs. Even devices from different vendors may not be truly 242 independent if they share common elements. Are they using the same 243 base chipset? Are they all running the same version of firmware? 244 Chipset and firmware bugs can happen, but they can be more difficult 245 to diagnose than application software bugs. When having the correct 246 time is of critical importance, it's ultimately up to operators to 247 ensure that their sources are sufficiently independent, even if they 248 are not under the operator's control. 250 A systemic problem with time from any satellite navigation service is 251 possible and has happened. Sunspot activity can render satellite or 252 radio-based time source unusable. If the time on your network has to 253 be correct close to 100% of the time, then even if you are using a 254 satellite-based system, operators need to plan for those rare 255 instances when the system is unavailable (or wrong!). 257 3.4. Control Messages 259 Some implementations of NTPv4 provide the NTP Control Messages that 260 were originally specified in Appendix B of [RFC1305] which defined 261 NTPv3. These messages were never included the NTPv4 specification, 262 but they are still used. Work is being done to formally document the 263 structure of these control messages in [I-D.ietf-ntp-mode-6-cmds]. 265 The NTP Control Messages are designed to permit monitoring and 266 optionally authenticated control of NTP and its configuration. Used 267 properly, these facilities provide vital debugging and performance 268 information and control. Used improperly, these facilities can be an 269 abuse vector. For this reason, it is RECOMMENDED that publicly- 270 facing NTP servers should block mode 6 queries from outside their 271 organization. 273 The ability to use Mode 6 beyond its basic monitoring capabilities 274 SHOULD be limited to authenticated sessions that provide a 275 'controlkey'. It MAY also be limited through mechanisms outside of 276 the NTP specification, such as Access Control Lists, that only allow 277 access from approved IP addresses. 279 The NTP Control Messages responses are much larger than the 280 corresponding queries. Thus, they can be abused in high-bandwidth 281 DDoS attacks. To provide protection for such abuse NTP server 282 operators on large networks SHOULD deploy ingress filtering in 283 accordance with BCP 38 [RFC2827]. 285 3.5. Monitoring 287 Operators SHOULD use their NTP implementation's remote monitoring 288 capabilities to quickly identify servers which are out of sync, and 289 ensure correctness of the service. Operators SHOULD also monitor 290 system logs for messages so problems and abuse attempts can be 291 quickly identified. 293 If a system starts getting unexpected time replies from its time 294 servers, that can be an indication that the IP address of the system 295 is being forged in requests to its time server. The goal of this 296 attack is to convince the time server to stop serving time to the 297 system whose address is being forged. 299 If a system is a broadcast client and its system log shows that it is 300 receiving early time messages from its server, that is an indication 301 that somebody may be forging packets from a broadcast server. 303 If a server's system log shows messages that indicates it is 304 receiving timestamps that are earlier than the current system time, 305 then either the system clock is unusually fast or somebody is trying 306 to launch a replay attack against that server. 308 3.6. Using Pool Servers 310 It only takes a small amount of bandwidth and system resources to 311 synchronize one NTP client, but NTP servers that can service tens of 312 thousands of clients take more resources to run. Users who want to 313 synchronize their computers SHOULD only synchronize to servers that 314 they have permission to use. 316 The NTP pool project is a group of volunteers who have donated their 317 computing and bandwidth resources to freely distribute time from 318 primary time sources to others on the Internet. The time is 319 generally of good quality, but comes with no guarantee whatsoever. 320 If you are interested in using the pool, please review their 321 instructions at http://www.pool.ntp.org/en/use.html [2]. 323 If you are a vendor who wishes to provide time service to your 324 customers or clients, consider joining the pool and providing a 325 "vendor zone" through the pool project. 327 If you want to synchronize many computers, consider running your own 328 NTP servers that are synchronized by the pool, and synchronizing your 329 clients to your in-house NTP servers. This reduces the load on the 330 pool. 332 3.7. Leap Second Handling 334 UTC is kept in agreement with the astronomical time UT1 [3] to within 335 +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap 336 second. UTC is an atomic time scale whereas UT1 is based on the 337 rotational rate of the earth. Leap seconds are not introduced at a 338 fixed rate. They are announced by the International Earth Rotation 339 and Reference Systems Service (IERS) in its Bulletin C [4] when 340 necessary to keep UTC and UT1 aligned. 342 NTP time is based on the UTC timescale, and the protocol has the 343 capability to broadcast leap second information. Some Global 344 Navigation Satellite Systems (like GPS) or radio transmitters (like 345 DCF77) broadcast leap second information, so if you are synced to an 346 NTP server that is ultimately synced to a source that provides leap 347 second notification you will get advance notification of impending 348 leap seconds automatically. 350 Since the length of the UT1 day is generally slowly increasing [5], 351 all leap seconds that have been introduced since the practice started 352 in 1972 have been positive leap seconds, where a second is added to 353 UTC. NTP also supports a negative leap second, where a second is 354 removed from UTC, if that ever becomes necessary. 356 While earlier versions of NTP contained some ambiguity regarding when 357 a leap second that is broadcast by a server should be applied by a 358 client, RFC 5905 is clear that leap seconds are only applied on the 359 last day of a month. However, because some older clients may apply 360 it at the end of the current day, it is RECOMMENDED that NTP servers 361 wait until the last day of the month before broadcasting leap 362 seconds. Doing this will prevent older clients from applying a leap 363 second at the wrong time. Note well that NTPv4's longest polling 364 interval exceeds one day and thus a leap second announcement may be 365 missed. 367 In circumstances where an NTP server is not receiving leap second 368 information from an automated source, certain organizations maintain 369 files which are updated every time a new leap second is announced: 371 NIST: ftp://time.nist.gov/pub/leap-seconds.list 373 US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap- 374 seconds.list 376 IERS (announces leap seconds): 377 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 379 3.7.1. Leap Smearing 381 Some NTP installations make use of a technique called Leap Smearing. 382 With this method, instead of introducing an extra second (or 383 eliminating a second) on a leap second event, NTP time will be slewed 384 in small increments over a comparably large window of time (called 385 the smear interval) around the leap second event. The smear interval 386 should be large enough to make the rate that the time is slewed 387 small, so that clients will follow the smeared time without 388 objecting. Periods ranging from 2 to 24 hours have been used 389 successfully. During the adjustment window, all the NTP clients' 390 times may be offset from UTC by as much as a full second, depending 391 on the implementation. But at least all clients will generally agree 392 on what time they think it is. 394 The purpose of Leap Smearing is to enable systems that don't deal 395 with the leap second event properly to function consistently, at the 396 expense of fidelity to UTC during the smear window. During a 397 standard leap second event, that minute will have 61 (or possibly 59) 398 seconds in it, and some applications (and even some OS's) are known 399 to have problems with that. 401 Operators who have legal obligations or other strong requirements to 402 be synchronized with UTC or civil time SHOULD NOT use leap smearing, 403 because the distributed time cannot be guaranteed to be traceable to 404 UTC during the smear interval. 406 Clients that are connected to leap smearing servers MUST NOT apply 407 the standard NTP leap second handling. So these clients must never 408 have a leap second file loaded, and the smearing servers must never 409 advertise to clients that a leap second is pending. 411 Any use of leap smearing servers should be limited to within a 412 single, well-controlled environment. Leap Smearing MUST NOT be used 413 for public-facing NTP servers, as they will disagree with non- 414 smearing servers (as well as UTC) during the leap smear interval, and 415 there is no standardized way for a client to detect that a server is 416 using leap smearing. However, be aware that some public-facing 417 servers may be configured this way anyway in spite of this guidance. 419 System Administrators are advised to be aware of impending leap 420 seconds and how the servers (inside and outside their organization) 421 they are using deal with them. Individual clients MUST NOT be 422 configured to use a mixture of smeared and non-smeared servers. If a 423 client uses smeared servers, the servers it uses must all have the 424 same leap smear configuration. 426 4. NTP Security Mechanisms 428 In the standard configuration NTP packets are exchanged unprotected 429 between client and server. An adversary that is able to become a 430 Man-In-The-Middle is therefore able to drop, replay or modify the 431 content of the NTP packet, which leads to degradation of the time 432 synchronization or the transmission of false time information. A 433 threat analysis for time synchronization protocols is given in 434 [RFC7384]. NTP provides two internal security mechanisms to protect 435 authenticity and integrity of the NTP packets. Both measures protect 436 the NTP packet by means of a Message Authentication Code (MAC). 437 Neither of them encrypts the NTP's payload, because this payload 438 information is not considered to be confidential. 440 4.1. Pre-Shared Key Approach 442 This approach applies a symmetric key for the calculation of the MAC, 443 which protects authenticity and integrity of the exchanged packets 444 for an association. NTP does not provide a mechanism for the 445 exchange of the keys between the associated nodes. Therefore, for 446 each association, keys SHOULD be exchanged securely by external 447 means, and they SHOULD be protected from disclosure. It is 448 RECOMMENDED that each association be protected by its own unique key. 449 It is RECOMMENDED that participants agree to refresh keys 450 periodically. However, NTP does not provide a mechanism to assist in 451 doing so. 453 [RFC5905] specifies a hash which must be supported for calculation of 454 the MAC, but other algorithms may be supported as well. The MD5 hash 455 is now considered to be too weak. Implementations will soon be 456 available based on AES-128-CMAC [I-D.ietf-ntp-mac], and users are 457 encouraged to use that when it is available. 459 To use this approach the communication partners have to exchange the 460 key, which consists of a keyid with a value between 1 and 65534, 461 inclusive, and a label which indicates the chosen digest algorithm. 462 Each communication partner adds this information to its own key file. 464 Some implementations store the key in clear text. Therefore it 465 SHOULD only be readable by the NTP process. Different keys are added 466 line by line to the key file. 468 An NTP client establishes a protected association by appending the 469 key to the server statement in its configuration file. Note that the 470 NTP process has to trust the applied key. 472 4.2. Autokey 474 Autokey was specified in 2010 to provide automated key management and 475 authentication of NTP servers. However, security researchers have 476 identified vulnerabilities [6] in the Autokey protocol. 478 Autokey SHOULD NOT be used. 480 4.3. Network Time Security 482 Work is in progress on an enhanced replacement for Autokey. Refer to 483 [I-D.ietf-ntp-using-nts-for-ntp] for more information. 485 5. NTP Security Best Practices 487 This section lists some general NTP security practices, but these 488 issues may (or may not) have been mitigated in particular versions of 489 particular implementations. Contact the maintainers of your 490 implementation for more information. 492 5.1. Minimizing Information Leakage 494 The base NTP packet leaks important information (including reference 495 ID and reference time) that may be used in attacks [NDSS16], 496 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 497 information by sending mode 3 queries to a target system and 498 inspecting the fields in the mode 4 response packet. NTP control 499 queries also leak important information (including reference ID, 500 expected origin timestamp, etc.) that may be used in attacks 501 [CVE-2015-8139]. A remote attacker can learn this information by 502 sending control queries to a target system and inspecting the 503 response. 505 As such, mechanisms outside of the NTP protocol, such as Access 506 Control Lists, SHOULD be used to limit the exposure of this 507 information to allowed IP addresses, and keep it from remote 508 attackers not on the list. Hosts SHOULD only respond to NTP control 509 queries from authorized parties. 511 A host that is not supposed to act as an NTP server that provides 512 timing information to other hosts MAY additionally log and drop 513 incoming mode 3 timing queries from unexpected sources. Note well 514 that the easiest way to monitor ntpd's status is to send it a mode 3 515 query. It is recommended that operators SHOULD filter mode 3 queries 516 at the edge, or make sure mode 3 queries are allowed only from 517 trusted systems or networks. 519 A "leaf-node host" is a host that is using NTP solely for the purpose 520 of adjusting its own system time. Such a host is not expected to 521 provide time to other hosts, and relies exclusively on NTP's basic 522 mode to take time from a set of servers. (That is, the host sends 523 mode 3 queries to its servers and receives mode 4 responses from 524 these servers containing timing information.) To minimize 525 information leakage, leaf-node hosts SHOULD drop all incoming NTP 526 packets except mode 4 response packets that come from known sources. 527 Note well that proper monitoring of an NTP server instance includes 528 checking the time of that NTP server instance. 530 Please refer to [I-D.ietf-ntp-data-minimization] for more 531 information. 533 5.2. Avoiding Daemon Restart Attacks 535 [RFC5905] says NTP clients should not accept time shifts greater than 536 the panic threshold. Specifically, RFC 5905 says "PANIC means the 537 offset is greater than the panic threshold PANICT (1000 s) and SHOULD 538 cause the program to exit with a diagnostic message to the system 539 log." 541 However, this behavior can be exploited by attackers as described in 542 [NDSS16], when the following two conditions hold: 544 1. The operating system automatically restarts the NTP client when 545 it quits. (Modern *NIX operating systems are replacing 546 traditional init systems with process supervisors, such as 547 systemd, which can be configured to automatically restart any 548 daemons that quit. This behavior is the default in CoreOS and 549 Arch Linux. It is likely to become the default behavior in other 550 systems as they migrate legacy init scripts to process 551 supervisors such as systemd.) 553 2. The NTP client is configured to ignore the panic threshold on all 554 restarts. 556 In such cases, if the attacker can send the target an offset that 557 exceeds the panic threshold, the client will quit. Then, when it 558 restarts, it ignores the panic threshold and accepts the attacker's 559 large offset. 561 Operators SHOULD be aware that when operating with the above two 562 conditions, the panic threshold offers no protection from attacks. 563 The natural solution is not to run hosts with these conditions. 564 Specifically, operators SHOULD NOT ignore the panic threshold in all 565 cold-start situations unless sufficient oversight and checking is in 566 place to make sure that this type of attack cannot happen. 568 As an alternative, the following steps MAY be taken by operators to 569 mitigate the risk of attack: 571 o Monitor the NTP system log to detect when the NTP daemon has quit 572 due to a panic event, as this could be a sign of an attack. 574 o Request manual intervention when a timestep larger than the panic 575 threshold is detected. 577 o Configure the ntp client to only ignore the panic threshold in a 578 cold start situation. 580 o Add 'minsane' and 'minclock' parameters to the ntp.conf file so 581 ntpd waits until enough trusted sources of time agree on the 582 correct time. 584 In addition, implementations SHOULD prevent the NTP daemon from 585 taking time steps that set the clock to a time earlier than the 586 compile date of the NTP daemon. 588 5.3. Detection of Attacks Through Monitoring 590 Operators SHOULD monitor their NTP instances to detect attacks. Many 591 known attacks on NTP have particular signatures. Common attack 592 signatures include: 594 1. Bogus packets - A packet whose origin timestamp does not match 595 the value that expected by the client. 597 2. Zero origin packet - A packet with an origin timestamp set to 598 zero [CVE-2015-8138]. 600 3. A packet with an invalid cryptographic MAC [CCR16]. 602 The observation of many such packets could indicate that the client 603 is under attack. 605 5.4. Kiss-o'-Death Packets 607 The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a 608 server can tell a misbehaving client to reduce its query rate. It is 609 RECOMMENDED that all NTP devices respect these packets and back off 610 when asked to do so by a server. It is even more important for an 611 embedded device, which may not have an exposed control interface for 612 NTP. 614 That said, a client MUST only accept a KoD packet if it has a valid 615 origin timestamp. Once a RATE packet is accepted, the client should 616 increase its poll interval value (thus decreasing its polling rate) 617 up to a reasonable maximum. This maximum can vary by implementation 618 but should not exceed a poll interval value of 13 (2 hours). The 619 mechanism to determine how much to increase the poll interval value 620 is undefined in [RFC5905]. If the client uses the poll interval 621 value sent by the server in the KoD packet, it MUST NOT simply accept 622 any value. Using large interval values may open a vector for a 623 denial-of-service attack that causes the client to stop querying its 624 server [NDSS16]. 626 The KoD mechanism relies on clients behaving properly in order to be 627 effective. Some clients ignore the KoD packet entirely, and other 628 poorly-implemented clients might unintentionally increase their poll 629 rate and simulate a denial of service attack. Server administrators 630 SHOULD be prepared for this and take measures outside of the NTP 631 protocol to drop packets from misbehaving clients when these clients 632 are detected. 634 Also, Kiss-o'-Death (KoD) packets can be used in denial of service 635 attacks. Thus, the observation of even just one KoD packet with a 636 high poll value could be sign that the client is under attack. 638 5.5. Broadcast Mode Should Only Be Used On Trusted Networks 640 Per [RFC5905], NTP's broadcast mode is authenticated using symmetric 641 key cryptography. The broadcast server and all of its broadcast 642 clients share a symmetric cryptographic key, and the broadcast server 643 uses this key to append a message authentication code (MAC) to the 644 broadcast packets it sends. 646 Importantly, all broadcast clients that listen to this server have to 647 know the cryptographic key. This mean that any client can use this 648 key to send valid broadcast messages that look like they come from 649 the broadcast server. Thus, a rogue broadcast client can use its 650 knowledge of this key to attack the other broadcast clients. 652 For this reason, an NTP broadcast server and all its clients have to 653 trust each other. Broadcast mode SHOULD only be run from within a 654 trusted network. 656 5.6. Symmetric Mode Should Only Be Used With Trusted Peers 658 In symmetric mode, two peers Alice and Bob can both push and pull 659 synchronization to and from each other using either ephemeral 660 symmetric passive (mode 2) or persistent symmetric active (NTP mode 661 1) packets. The persistent association is preconfigured and 662 initiated at the active peer but not preconfigured at the passive 663 peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob 664 mobilizes a new ephemeral association if he does not have one 665 already. This is a security risk for Bob because an arbitrary 666 attacker can attempt to change Bob's time by asking Bob to become its 667 symmetric passive peer. 669 For this reason, a host SHOULD only allow symmetric passive 670 associations to be established with trusted peers. Specifically, a 671 host SHOULD require each of its symmetric passive association to be 672 cryptographically authenticated. Each symmetric passive association 673 SHOULD be authenticated under a different cryptographic key. 675 6. NTP in Embedded Devices 677 As computing becomes more ubiquitous, there will be many small 678 embedded devices that require accurate time. These devices may not 679 have a persistent battery-backed clock, so using NTP to set the 680 correct time on power-up may be critical for proper operation. These 681 devices may not have a traditional user interface, but if they 682 connect to the Internet they will be subject to the same security 683 threats as traditional deployments. 685 6.1. Updating Embedded Devices 687 Vendors of embedded devices MUST pay attention to the current state 688 of protocol security issues and bugs in their chosen implementation, 689 because their customers don't have the ability to update their NTP 690 implementation on their own. Those devices may have a single 691 firmware upgrade, provided by the manufacturer, that updates all 692 capabilities at once. This means that the vendor assumes the 693 responsibility of making sure their devices have the latest NTP 694 updates applied. 696 Vendors of embedded devices SHOULD also include the ability to update 697 information regarding which NTP server to connect to on these 698 devices. 700 There is a catalog of NTP server abuse incidents, some of which 701 involve embedded devices, on the Wikipedia page for NTP Server Misuse 702 and Abuse [7]. 704 6.2. Server configuration 706 Vendors of embedded devices that need time synchronization SHOULD 707 also carefully consider where they get their time from. There are 708 several public-facing NTP servers available, but they may not be 709 prepared to service requests from thousands of new devices on the 710 Internet. Vendors SHOULD only synchronize to servers that they have 711 permission to use. 713 Vendors are encouraged to invest resources into providing their own 714 time servers for their devices to connect to. 716 Vendors should read [RFC4085], which advises against embedding 717 globally-routable IP addresses in products, and offers several better 718 alternatives. 720 6.2.1. NTP Pool Project Vendor Subdomains 722 The NTP Pool Project offers a program where vendors can obtain their 723 own subdomain that is part of the NTP Pool. This offers vendors the 724 ability to safely make use of the time distributed by the Pool for 725 their devices. Vendors are encouraged to support the pool if they 726 participate. For more information, visit http://www.pool.ntp.org/en/ 727 vendors.html [8] . 729 7. NTP over Anycast 731 Anycast is described in BCP 126 [RFC4786]. (Also see [RFC7094]). 732 With anycast, a single IP address is assigned to multiple interfaces, 733 and routers direct packets to the closest active interface. 735 Anycast is often used for Internet services at known IP addresses, 736 such as DNS. Anycast can also be used in large organizations to 737 simplify configuration of a large number of NTP clients. Each client 738 can be configured with the same NTP server IP address, and a pool of 739 anycast servers can be deployed to service those requests. New 740 servers can be added to or taken from the pool, and other than a 741 temporary loss of service while a server is taken down, these 742 additions can be transparent to the clients. 744 Note well that using a single anycast address for NTP presents its 745 own potential issues. It means each client will likely use a single 746 time server source. A key element of a robust NTP deployment is each 747 client using multiple sources of time. With multiple time sources, a 748 client will analyze the various time sources, selecting good ones, 749 and disregarding poor ones. If a single Anycast address is used, 750 this analysis will not happen. 752 If clients are connected to an NTP server via anycast, the client 753 does not know which particular server they are connected to. As 754 anycast servers may arbitrarily enter and leave the network, the 755 server a particular client is connected to may change. This may 756 cause a small shift in time from the perspective of the client when 757 the server it is connected to changes. It is RECOMMENDED that 758 anycast only be deployed in environments where these small shifts can 759 be tolerated. 761 Configuration of an anycast interface is independent of NTP. Clients 762 will always connect to the closest server, even if that server is 763 having NTP issues. It is RECOMMENDED that anycast NTP 764 implementations have an independent method of monitoring the 765 performance of NTP on a server. If the server is not performing to 766 specification, it should remove itself from the Anycast network. It 767 is also RECOMMENDED that each Anycast NTP server have an alternative 768 method of access, such as an alternate Unicast IP address, so its 769 performance can be checked independently of the anycast routing 770 scheme. 772 One useful application in large networks is to use a hybrid unicast/ 773 anycast approach. Stratum 1 NTP servers can be deployed with unicast 774 interfaces at several sites. Each site may have several Stratum 2 775 servers with two ethernet interfaces, or a single interface which can 776 support multiple addresses. One interface has a unique unicast IP 777 address. The second has an anycast IP interface (with a shared IP 778 address per location). The unicast interfaces can be used to obtain 779 time from the Stratum 1 servers globally (and perhaps peer with the 780 other Stratum 2 servers at their site). Clients at each site can be 781 configured to use the shared anycast address for their site, 782 simplifying their configuration. Keeping the anycast routing 783 restricted on a per-site basis will minimize the disruption at the 784 client if its closest anycast server changes. Each Stratum 2 server 785 can be uniquely identified on their unicast interface, to make 786 monitoring easier. 788 8. Acknowledgments 790 The authors wish to acknowledge the contributions of Sue Graves, 791 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 792 Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, 793 Robert Nagy, and Brian Haberman. 795 9. IANA Considerations 797 This memo includes no request to IANA. 799 10. Security Considerations 801 Time is a fundamental component of security on the internet. The 802 absence of a reliable source of current time subverts many common web 803 authentication schemes, e.g., by allowing the use of expired 804 credentials or by allowing for replay of messages only intended to be 805 processed once. 807 Much of this document directly addresses how to secure NTP servers. 808 In particular, see Section 2, Section 4, and Section 5. 810 There are several general threats to time synchronization protocols 811 which are discussed in [RFC7384]. 813 [I-D.ietf-ntp-using-nts-for-ntp] specifies the Network Time Security 814 (NTS) mechanism and applies it to NTP. Readers are encouraged to 815 check the status of the draft, and make use of the methods it 816 describes. 818 11. References 820 11.1. Normative References 822 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 823 Defeating Denial of Service Attacks which employ IP Source 824 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 825 May 2000, . 827 [RFC4085] Plonka, D., "Embedding Globally-Routable Internet 828 Addresses Considered Harmful", BCP 105, RFC 4085, 829 DOI 10.17487/RFC4085, June 2005, 830 . 832 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 833 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 834 December 2006, . 836 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 837 "Network Time Protocol Version 4: Protocol and Algorithms 838 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 839 . 841 11.2. Informative References 843 [BCP38INFO] 844 "BCP38 Info Page", . 846 [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's 847 Authenticated Broadcast Mode", SIGCOMM Computer 848 Communications Review (CCR) , 2016. 850 [CVE-2015-8138] 851 Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL 852 ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 853 . 855 [CVE-2015-8139] 856 Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC 857 ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 858 . 860 [CVE-2016-1548] 861 Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode 862 to Interleaved", 2016, 863 . 866 [I-D.ietf-ntp-data-minimization] 867 Franke, D. and A. Malhotra, "NTP Client Data 868 Minimization", draft-ietf-ntp-data-minimization-03 (work 869 in progress), September 2018. 871 [I-D.ietf-ntp-mac] 872 Malhotra, A. and S. Goldberg, "Message Authentication Code 873 for the Network Time Protocol", draft-ietf-ntp-mac-05 874 (work in progress), October 2018. 876 [I-D.ietf-ntp-mode-6-cmds] 877 Haberman, B., "Control Messages Protocol for Use with 878 Network Time Protocol Version 4", draft-ietf-ntp-mode- 879 6-cmds-06 (work in progress), September 2018. 881 [I-D.ietf-ntp-using-nts-for-ntp] 882 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 883 Sundblad, "Network Time Security for the Network Time 884 Protocol", draft-ietf-ntp-using-nts-for-ntp-14 (work in 885 progress), October 2018. 887 [IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C., 888 Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla: 889 The Rise and Decline of NTP DDoS Attacks", Internet 890 Measurement Conference , 2014. 892 [MILLS2006] 893 Mills, D., "Computer network time synchronization: the 894 Network Time Protocol", CRC Press , 2006. 896 [NDSS14] Rossow, C., "Amplification Hell: Revisiting Network 897 Protocols for DDoS Abuse", NDSS'14, San Diego, CA. , 2014. 899 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 900 "Attacking the Network Time Protocol", NDSS'16, San Diego, 901 CA. , 2016, . 903 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 904 Specification, Implementation and Analysis", RFC 1305, 905 DOI 10.17487/RFC1305, March 1992, 906 . 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, 910 DOI 10.17487/RFC2119, March 1997, 911 . 913 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 914 "Architectural Considerations of IP Anycast", RFC 7094, 915 DOI 10.17487/RFC7094, January 2014, 916 . 918 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 919 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 920 October 2014, . 922 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 923 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 924 May 2017, . 926 11.3. URIs 928 [1] https://blog.cloudflare.com/technical-details-behind-a-400gbps- 929 ntp-amplification-ddos-attack/ 931 [2] http://www.pool.ntp.org/en/use.html 933 [3] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 935 [4] https://www.iers.org/IERS/EN/Publications/Bulletins/ 936 bulletins.html 938 [5] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 940 [6] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html 942 [7] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 944 [8] http://www.pool.ntp.org/en/vendors.html 946 [9] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno 948 [10] https://support.ntp.org/bin/view/Support/ConfiguringNTP 950 Appendix A. NTP Implementation by the Network Time Foundation 952 The Network Time Foundation (NTF) provides the reference 953 implementation of NTP, well-known under the name "ntpd". It is 954 actively maintained and developed by NTF's NTP Project, with help 955 from volunteers and NTF's supporters. This NTP software can be 956 downloaded from 958 A.1. Use enough time sources 960 In addition to the recommendation given in Section Section 3.2 the 961 ntpd implementation provides the 'pool' directive. Starting with 962 ntp-4.2.6, this directive will spin up enough associations to provide 963 robust time service, and will disconnect poor servers and add in new 964 servers as-needed. If you have good reason, you may use the 965 'minclock' and 'maxclock' options of the 'tos' command to override 966 the default values of how many servers are discovered through the 967 'pool' directive. 969 A.2. NTP Control and Facility Messages 971 In addition to NTP Control Messages the ntpd implementation also 972 offers the Mode 7 commands for monitoring and configuration. 974 If Mode 7 has been explicitly enabled to be used for more than basic 975 monitoring it should be limited to authenticated sessions that 976 provide a 'requestkey'. 978 As mentioned above, there are two general ways to use Mode 6 and Mode 979 7 requests. One way is to query ntpd for information, and this mode 980 can be disabled with: 982 restrict ... noquery 984 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 985 behavior. Modification of ntpd's configuration requires an 986 authenticated session by default. If no authentication keys have 987 been specified no modifications can be made. For additional 988 protection, the ability to perform these modifications can be 989 controlled with: 991 restrict ... nomodify 993 Users can prevent their NTP servers from considering query/ 994 configuration traffic by default by adding the following to their 995 ntp.conf file: 997 restrict default -4 nomodify notrap nopeer noquery 998 restrict default -6 nomodify notrap nopeer noquery 1000 restrict source nomodify notrap noquery 1001 # nopeer is OK if you don't use the 'pool' directive 1003 A.3. Monitoring 1005 The reference implementation of NTP allows remote monitoring. Access 1006 to this service is generally controlled by the "noquery" directive in 1007 NTP's configuration file (ntp.conf) via a "restrict" statement. The 1008 syntax reads: 1010 restrict address mask address_mask noquery 1012 If a system is using broadcast mode and is running ntp-4.2.8p6 or 1013 later, use the 4th field of the ntp.keys file to specify the IPs of 1014 machines that are allowed to serve time to the group. 1016 A.4. Leap Second File 1018 The use of leap second files requires ntpd 4.2.6 or later. After 1019 fetching the leap seconds file onto the server, add this line to 1020 ntpd.conf to apply and use the file: 1022 leapfile "/path/to your/leap-file" 1024 You may need to restart ntpd to apply this change. 1026 ntpd servers with a manually configured leap second file will ignore 1027 leap second information broadcast from upstream NTP servers until the 1028 leap second file expires. If no valid leap second file is available 1029 then a leap second notification from an attached reference clock is 1030 always accepted by ntpd. 1032 If no valid leap second file is available, a leap second notification 1033 may be accepted from upstream NTP servers. As of ntp-4.2.6, a 1034 majority of servers must provide the notification before it is 1035 accepted. Before 4.2.6, a leap second notification would be accepted 1036 if a single upstream server of a group of configured servers provided 1037 a leap second notification. This would lead to misbehavior if single 1038 NTP servers sent an invalid leap second warning, e.g. due to a faulty 1039 GPS receiver in one server, but this behavior was once chosen because 1040 in the "early days" there was a greater chance that leap second 1041 information would be available from a very limited number of sources. 1043 A.5. Leap Smearing 1045 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in 1046 response to client requests. Support for leap smearing is not 1047 configured by default and must be added at compile time. In 1048 addition, no leap smearing will occur unless a leap smear interval is 1049 specified in ntpd.conf . For more information, refer to 1050 http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [9]. 1052 A.6. Configuring ntpd 1054 See https://support.ntp.org/bin/view/Support/ConfiguringNTP [10] for 1055 additional information on configuring ntpd. 1057 A.7. Pre-Shared Keys 1059 Each communication partner must add the keyid information to their 1060 key file in the form: 1062 keyid label key 1064 An ntpd client establishes a protected association by appending the 1065 option "key keyid" to the server statement in ntp.conf: 1067 server address key keyid 1069 A key is deemed trusted when its keyid is added to the list of 1070 trusted keys by the "trustedkey" statement in ntp.conf. 1072 trustedkey keyid_1 keyid_2 ... keyid_n 1074 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 1075 column, a comma-separated list of IPs that are allowed to serve time. 1076 Use this feature. Note, however, that an adversarial client that 1077 knows the symmetric broadcast key could still easily spoof its source 1078 IP to an IP that is allowed to serve time. (This is easy to do 1079 because the origin timestamp on broadcast mode packets is not 1080 validated by the client. By contrast, client/server and symmetric 1081 modes do require origin timestamp validation, making it more 1082 difficult to spoof packets [CCR16]. 1084 Authors' Addresses 1085 Denis Reilly (editor) 1086 Orolia USA 1087 1565 Jefferson Road, Suite 460 1088 Rochester, NY 14623 1089 US 1091 Email: denis.reilly@orolia.com 1093 Harlan Stenn 1094 Network Time Foundation 1095 P.O. Box 918 1096 Talent, OR 97540 1097 US 1099 Email: stenn@nwtime.org 1101 Dieter Sibold 1102 Physikalisch-Technische Bundesanstalt 1103 Bundesallee 100 1104 Braunschweig D-38116 1105 Germany 1107 Phone: +49-(0)531-592-8420 1108 Fax: +49-531-592-698420 1109 Email: dieter.sibold@ptb.de