idnits 2.17.1 draft-ietf-ntp-bcp-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5905]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2018) is 2067 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 879 -- Looks like a reference, but probably isn't: '2' on line 881 -- Looks like a reference, but probably isn't: '3' on line 883 -- Looks like a reference, but probably isn't: '4' on line 885 -- Looks like a reference, but probably isn't: '5' on line 887 -- Looks like a reference, but probably isn't: '6' on line 890 -- Looks like a reference, but probably isn't: '7' on line 892 -- Looks like a reference, but probably isn't: '8' on line 894 -- Looks like a reference, but probably isn't: '9' on line 896 -- Looks like a reference, but probably isn't: '10' on line 898 -- Looks like a reference, but probably isn't: '11' on line 917 -- Looks like a reference, but probably isn't: '12' on line 1011 -- Looks like a reference, but probably isn't: '13' on line 1015 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 7094 ** Downref: Normative reference to an Informational RFC: RFC 7384 == Outdated reference: A later version (-11) exists of draft-ietf-ntp-mode-6-cmds-05 == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-12 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 15 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 Spectracom 4 Intended status: Best Current Practice H. Stenn 5 Expires: February 1, 2019 Network Time Foundation 6 D. Sibold 7 PTB 8 July 31, 2018 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-07 13 Abstract 15 NTP Version 4 (NTPv4) has been widely used since its publication as 16 RFC 5905 [RFC5905]. This documentation is a collection of Best 17 Practices from across the NTP community. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 1, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Keeping NTP up to date . . . . . . . . . . . . . . . . . . . 3 56 3. General Network Security Best Practices . . . . . . . . . . . 4 57 3.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 59 4.1. Use enough time sources . . . . . . . . . . . . . . . . . 4 60 4.2. Use a diversity of Reference Clocks . . . . . . . . . . . 5 61 4.3. Control Messages . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 64 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 7 65 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 8 66 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 9 67 5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 9 68 5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.3. Network Time Security . . . . . . . . . . . . . . . . . . 10 70 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 10 71 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 10 72 6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 11 73 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 12 74 6.4. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 13 75 6.5. Broadcast Mode Should Only Be Used On Trusted Networks . 13 76 6.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 14 77 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 78 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 15 79 7.2. Server configuration . . . . . . . . . . . . . . . . . . 15 80 7.2.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 15 81 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 12.2. Informative References . . . . . . . . . . . . . . . . . 18 88 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 Appendix A. Implementation Specific Information . . . . . . . . 20 90 A.1. NTP Implementation by the Network Time Foundation 20 91 A.1.1. Use enough time sources . . . . . . . . . . . . . . . 20 92 A.1.2. NTP Control and Facility Messages . . . . . . . . . . 20 93 A.1.3. Monitoring . . . . . . . . . . . . . . . . . . . . . 21 94 A.1.4. Leap Second File . . . . . . . . . . . . . . . . . . 21 95 A.1.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . 22 96 A.1.6. Configuring ntpd . . . . . . . . . . . . . . . . . . 22 97 A.1.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 NTP Version 4 (NTPv4) has been widely used since its publication as 103 RFC 5905 [RFC5905]. This documentation is a collection of Best 104 Practices from across the NTP community. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Keeping NTP up to date 114 Many network security mechanisms rely on time as part of their 115 operation. If attackers can spoof the time, they may be able to 116 bypass or neutralize other security elements. For example, incorrect 117 time can disrupt the ability to reconcile logfile entries on the 118 affected system with events on other systems. The best way to detect 119 and protect computers and networks against undefined behavior and 120 security threats related to time is to keep their NTP implementations 121 current, use an appropriate number of trustworthy time sources, and 122 properly monitor their time infrastructure. 124 There are always new ideas about security on the Internet, and an 125 application which is secure today could be insecure tomorrow once an 126 unknown bug (or a known behavior) is exploited in the right way. 127 Even our definition of what is secure has evolved over the years, so 128 code which was considered secure when it was written may turn out to 129 be insecure after some time. By keeping NTP implementations current, 130 having "enough" trustworthy time sources, and properly monitoring 131 their time infrastructure, network operators can make sure that their 132 time infrastructure is operating correctly and within specification, 133 and is not being attacked or misused. 135 There are multiple versions of the NTP protocol in use, and multiple 136 implementations in use, on many different platforms. It is 137 recommended that that NTP users select an implementation that is 138 actively maintained. Users should keep up to date on any known 139 attacks on their selected implementation, and deploy updates 140 containing security fixes as soon as practical. 142 3. General Network Security Best Practices 144 3.1. BCP 38 146 Many network attacks rely on modifying the IP source address of a 147 packet to point to a different IP address than the computer which 148 originated it. UDP-based protocols such as NTP are generally more 149 susceptible to spoofing attacks then other connection-oriented 150 protocols. NTP control messages can generate a lot of data in 151 response to a small query, which makes it more attractive as a vector 152 for distributed denial-of-service attacks. (NTP Control messages are 153 discussed further in Section 4.3). Mitigating source address 154 spoofing attacks should be a priority of anyone administering NTP. 156 BCP 38 [RFC2827] was approved in 2000 to address this. BCP 38 157 [RFC2827] calls for filtering outgoing and incoming traffic to make 158 sure that the source and destination IP addresses are consistent with 159 the expected flow of traffic on each network interface. It is 160 recommended that all networks (and ISP's of any size) implement 161 ingress and egress filtering. More information is available at the 162 BCP38 Info page [1] . 164 4. NTP Configuration Best Practices 166 This section provides general Best Practices. Best Practices that 167 are implementation specific are compilied in Section Appendix A. 169 4.1. Use enough time sources 171 An NTP implementation (as opposed to an SNTP implementation) takes 172 the available sources of time and submits this timing data to 173 sophisticated intersection, clustering, and combing algorithms to get 174 the best estimate of the correct time. The description of these 175 algorithms is beyond the scope of this document. Interested readers 176 should read RFC 5905 [RFC5905] or the detailed description of NTP in 177 MILLS 2006 [MILLS2006] 179 o If there is only 1 source of time, the answer is obvious. It may 180 not be a good source of time, but it's the only source of time 181 that can be considered. Any issue with the time at the source 182 will be passed on to the client. 184 o If there are 2 sources of time and they agree well enough, then 185 the best "time" can be calculated easily. But if one source 186 fails, then the solution degrades to the single-source solution 187 outlined above. And if the two sources don't agree, then it's 188 impossible to know which one is correct by simply looking at the 189 time. 191 o If there are 3 sources of time, there is more data available to 192 converge on a "best" time, and this time is more likely to be 193 accurate. And the loss of one of the sources (by becoming 194 unreachable or unusable) can be tolerated. But at that point, the 195 solution degrades to the 2 source solution. 197 o 4 or more sources of time is better. If one of these sources 198 develops a problem there are still at least 3 other time sources. 200 But even with 4 or more sources of time, systemic problems can 201 happen. During the leap second of June of 2015, several operators 202 implemented leap smearing while others did not, and many NTP end 203 nodes could not determine an accurate time source because 2 of their 204 4 sources of time gave them consistent UTC/POSIX time, while the 205 other 2 gave them consistent leap-smeared time. See Section 4.6.1 206 for more information. 208 Monitor your NTP instances. If your time sources do not generally 209 agree, find out why and either correct the problems or stop using 210 defective servers. See Section 4.4 for more information. 212 4.2. Use a diversity of Reference Clocks 214 When using servers with attached hardware reference clocks, it is 215 recommended that several different types of reference clocks be used. 216 Having a diversity of sources means that any one issue is less likely 217 to cause a service interruption. 219 Are all clocks on a network from the same vendor? They may have the 220 same bugs. Are they using the same base chipset, regardless of 221 whether or not the finished products are from different vendors? Are 222 they all running the same version of firmware? Chipset and firmware 223 bugs can happen, but they can be more difficult to diagnose than 224 application software bugs. 226 A systemic problem with time from any satellite navigation service is 227 possible and has happened. Sunspot activity can render satellite or 228 radio-based time source unusable. If the time on your network must 229 be correct close to 100% of the time, then even if you are using a 230 satellite-based system, you must plan for those rare instances when 231 the system is unavailable (or wrong!). 233 4.3. Control Messages 235 Some implementations of NTPv4 provide the NTP Control Messages which 236 originally have been specified in Appendix B of [RFC1305] which 237 defined NTPv3, but never have been part of the NTPv4 specification. 239 (Work is being done to formally document the structure of these 240 control messages in draft-ietf-ntp-mode-6-cmds [CTRLMSG] .) 242 The NTP Control Messages are designed to permit monitoring and 243 optionally authenticated control of NTP and its configuration. Used 244 properly, these facilities provide vital debugging and performance 245 information and control. Used improperly, these facilities can be an 246 abuse vector. 248 The ability to use Mode 6 beyond its basic monitoring capabilities 249 can be limited to authenticated sessions that provide a 'controlkey'. 251 The NTP Control Messages responses are much larger than the 252 corresponding queries. Thus, they can be abused in high-bandwidth 253 DDoS attacks. To provide protection for such abuse NTP server 254 operators should deploy ingress filtering BCP 38 [RFC2827]. 256 4.4. Monitoring 258 Use your NTP implementation's remote monitoring capabilities to 259 quickly identify servers which are out of sync, and ensure 260 correctness of the service. Monitor system logs for messages so 261 problems and abuse attempts can be quickly identified. 263 If a system starts getting unexpected time replies from its time 264 servers, that can be an indication that the IP address of the system 265 is being forged in requests to its time server, and these abusers are 266 trying to convince that time server to stop serving time to that 267 system. 269 If a system is a broadcast client and its syslog shows that it is 270 receiving "early" time messages from its server, that is an 271 indication that somebody may be forging packets from a broadcast 272 server. 274 If a server's syslog shows messages that indicates it is receiving 275 timestamps that are earlier than the current system time, then either 276 the system clock is unusually fast or somebody is trying to launch a 277 replay attack against that server. 279 If a system is using broadcast mode and is running ntp-4.2.8p6 or 280 later, use the 4th field of the ntp.keys file to specify the IPs of 281 machines that are allowed to serve time to the group. 283 4.5. Using Pool Servers 285 It only takes a small amount of bandwidth and system resources to 286 synchronize one NTP client, but NTP servers that can service tens of 287 thousands of clients take more resources to run. Users who want to 288 synchronize their computers should only synchronize to servers that 289 they have permission to use. 291 The NTP pool project is a group of volunteers who have donated their 292 computing and bandwidth resources to freely distribute time from 293 primary time sources to others on the Internet. The time is 294 generally of good quality, but comes with no guarantee whatsoever. 295 If you are interested in using the pool, please review their 296 instructions at http://www.pool.ntp.org/en/use.html [2]. 298 If you are a vendor who wishes to provide time service to your 299 customers or clients, consider joining the pool and providing a 300 "vendor zone" through the pool project. 302 If you want to synchronize many computers, consider running your own 303 NTP servers that are synchronized by the pool, and synchronizing your 304 clients to your in-house NTP servers. This reduces the load on the 305 pool. 307 If you would like to contribute a server with a static IP address and 308 a permanent Internet connection to the pool, please consult the 309 instructions at http://www.pool.ntp.org/en/join.html [3] . 311 4.6. Leap Second Handling 313 UTC is kept in agreement with the astronomical time UT1 [4] to within 314 +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap 315 second. UTC is an atomic time scale whereas UT1 is based on the 316 rotational rate of the earth. Leap seconds are not introduced at a 317 fixed rate. They are announced by the IERS (International Earth 318 Rotation and Reference Systems Service) in its Bulletin C [5] when 319 necessary to keep UTC and UT1 aligned. 321 NTP time is based on the UTC timescale, and the protocol has the 322 capability to broadcast leap second information. Some GNSS systems 323 (like GPS) or radio transmitters (like DCF77) broadcast leap second 324 information, so if you are synced to an ntp server that is ultimately 325 synced to a source that provides leap second notification you will 326 get advance notification of impending leap seconds automatically. 328 Since the length of the UT1 day is generally slowly increasing [6], 329 all leap seconds that have been introduced since the practice started 330 in 1972 have been "positive" leap seconds, where a second is added to 331 UTC. NTP also supports a "negative" leap second, where a second is 332 removed from UTC, should that ever become necessary. 334 While earlier versions of NTP contained some ambiguity regarding when 335 a leap second that is broadcast by a server should be applied by a 336 client, RFC 5905 is clear that leap seconds are only applied on the 337 last day of a month. However, because some older clients may apply 338 it at the end of the current day, it is recommended that NTP servers 339 wait until the last day of the month before broadcasting leap 340 seconds. Doing this will prevent older clients from applying a leap 341 second at the wrong time. Note well that NTPv4 allows a maximum poll 342 interval of 17, or 131,072 seconds, which is longer than a day. 344 The IETF maintains a leap second list [7] for NTP users who are not 345 receiving leap second information through an automatic source. 347 Files are also available from other sources: 349 NIST: ftp://time.nist.gov/pub/leap-seconds.list 351 US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap- 352 seconds.list 354 IERS (announces leap seconds): 355 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 357 See Appendix A.1.4 for instructions on applying the leap second file 358 to the reference implementation. 360 4.6.1. Leap Smearing 362 Some NTP installations may instead make use of a technique called 363 "Leap Smearing". With this method, instead of introducing an extra 364 second (or eliminating a second), NTP time will be slewed in small 365 increments over a comparably large window of time (called the smear 366 interval) around the leap second event. The smear interval should be 367 large enough to make the rate that the time is slewed small, so that 368 clients will follow the smeared time without objecting. Periods 369 ranging from 2 to 24 hours have been used sucessfully. During the 370 adjustment window, all the NTP clients' times may be offset from UTC 371 by as much as a full second, depending on the implementation. But at 372 least all clients will generally agree on what time they think it is! 374 NOTE WELL that using a leap-smear can cause your reported time to be 375 "legally indefensible" and/or be a breach of compliance regulations. 377 The purpose of Leap Smearing is to enable systems that don't deal 378 with the leap second event properly to function consistently, at the 379 expense of fidelity to UTC during the smear window. During a 380 standard leap second event, that minute will have 61 (or possibly 59) 381 seconds in it, and some applications (and even some OS's) are known 382 to have problems with that. 384 Clients that are connected to leap smearing servers MUST NOT apply 385 the "standard" NTP leap second handling. So if they are using ntpd, 386 these clients must never have a leap second file loaded, and the 387 smearing servers must never advertise to clients that a leap second 388 is pending. 390 Leap Smearing MUST NOT be used for public-facing NTP servers, as they 391 will disagree with non-smearing servers (as well as UTC) during the 392 leap smear interval. However, be aware that some public-facing 393 servers may be configured this way anyway in spite of this guidance. 395 System Administrators are advised to be aware of impending leap 396 seconds and how the servers (inside and outside their organization) 397 they are using deal with them. Individual clients must never be 398 configured to use a mixture of smeared and non-smeared servers. If a 399 client uses smeared servers, the servers it uses must all have the 400 same leap smear configuration. 402 5. NTP Security Mechanisms 404 In the standard configuration NTP packets are exchanged unprotected 405 between client and server. An adversary that is able to become a 406 Man-In-The-Middle is therefore able to drop, replay or modify the 407 content of the NTP packet, which leads to degradation of the time 408 synchronization or the transmission of false time information. A 409 profound threat analysis for time synchronization protocols are given 410 in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms 411 to protect authenticity and integrity of the NTP packets. Both 412 measures protect the NTP packet by means of a Message Authentication 413 Code (MAC). Neither of them encrypts the NTP's payload, because this 414 payload information is not considered to be confidential. 416 5.1. Pre-Shared Key Approach 418 This approach applies a symmetric key for the calculation of the MAC, 419 which protects authenticity and integrity of the exchanged packets 420 for an association. NTP does not provide a mechanism for the 421 exchange of the keys between the associated nodes. Therefore, for 422 each association, keys have to be exchanged securely by external 423 means. It is recommended that each association be protected by its 424 own unique key. NTP does not provide a mechanism to automatically 425 refresh the applied keys. It is therefore recommended that the 426 participants periodically agree on a fresh key. The calculation of 427 the MAC may always be based on an MD5 hash, and an AES-128-CMAC hash 428 is expected to soon be allowed as well. If the NTP daemon is built 429 against an OpenSSL library, NTP can also base the calculation of the 430 MAC upon any other digest algorithm supported by each side's OpenSSL 431 library. 433 To use this approach the communication partners have to exchange the 434 key, which consists of a keyid with a value between 1 and 65534, 435 inclusive, and a label which indicates the chosen digest algorithm. 436 Each communication partner adds this information to its own key file. 438 Some implementations store the key in clear text. Therefore it 439 should only be readable by the NTP process. Different keys are added 440 line by line to the key file. 442 An NTP client establishes a protected association by appending the 443 key to the server statement in its configuration file. Note that the 444 NTP process has to trust the applied key. 446 5.2. Autokey 448 Autokey was designed in 2003 to provide a means for clients to 449 authenticate servers. However, security researchers have identified 450 vulnerabilities in the Autokey protocol, which make the protocol 451 "useless". [8] 453 Autokey SHOULD NOT BE USED. 455 5.3. Network Time Security 457 Work is in progress on an enhanced replacement for Autokey, which is 458 called Network Time Security (NTS) [NTSFORNTP]. As of July 2018, 459 this effort was at draft #12, and in the 'Working Group Last Call' 460 process. Readers are encouraged to adopt its mechanisms. 462 6. NTP Security Best Practices 464 This section lists some general NTP security practices, but these 465 concepts may (or may not) have been mitigated in particular versions 466 of particular implementations. Contact the maintainers of your 467 implementation for more information. 469 6.1. Minimizing Information Leakage 471 The base NTP packet leaks important information (including reference 472 ID and reference time) that may be used in attacks [NDSS16], 473 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 474 information by sending mode 3 queries to a target system and 475 inspecting the fields in the mode 4 response packet. NTP control 476 queries also leak important information (including reference ID, 477 expected origin timestamp, etc.) that may be used in attacks 478 [CVE-2015-8139]. A remote attacker can learn this information by 479 sending control queries to a target system and inspecting the 480 response. 482 As such, access control should be used to limit the exposure of this 483 information to inappropriate third parties. 485 Hosts should only respond to NTP control queries from authorized 486 parties. One way to do this is to only allow control queries from 487 authenticated sources via authorized IP addresses. 489 A host that is not supposed to act as an NTP server that provides 490 timing information to other hosts may additionally log and drop 491 incoming mode 3 timing queries from unexpected sources. Note well 492 that the easiest way to monitor ntpd's status is to send it a mode 3 493 query. A much better approach might be to filter mode 3 queries at 494 the edge, or make sure mode 3 queries are allowed only from trusted 495 systems or networks. 497 A "leaf-node host" is a host that is using NTP solely for the purpose 498 of adjusting its own system time. Such a host is not expected to 499 provide time to other hosts, and relies exclusively on NTP's basic 500 mode to take time from a set of servers. (That is, the host sends 501 mode 3 queries to its servers and receives mode 4 responses from 502 these servers containing timing information.) To minimize 503 information leakage, leaf-node hosts should drop all incoming NTP 504 packets except mode 4 response packets that come from known sources. 505 Note well that proper monitoring of an ntpd instance includes 506 checking the time of that ntpd instance. 508 6.2. Avoiding Daemon Restart Attacks 510 RFC 5905 [RFC5905] says NTP clients should not accept time shifts 511 greater than the panic threshold. Specifically, RFC 5905 says "PANIC 512 means the offset is greater than the panic threshold PANICT (1000 s) 513 and SHOULD cause the program to exit with a diagnostic message to the 514 system log." 516 However, this behavior can be exploited by attackers [NDSS16], when 517 the following two conditions hold: 519 1. The operating system automatically restarts the NTP daemon when 520 it quits. (Modern *NIX operating systems are replacing 521 traditional init systems with process supervisors, such as 522 systemd, which can be configured to automatically restart any 523 daemons that quit. This behavior is the default in CoreOS and 524 Arch Linux. It is likely to become the default behavior in other 525 systems as they migrate legacy init scripts to process 526 supervisors such as systemd.) 528 2. If, against long-standing recommendation, ntpd is always started 529 with the -g option, it will ignore the panic threshold when it is 530 restarted. The -g option SHOULD only be provided in cold-start 531 situations. 533 In such cases, if the attacker can send the target an offset that 534 exceeds the panic threshold, the client will quit. Then, when the 535 client restarts, it ignores the panic threshold and accepts the 536 attacker's large offset. 538 Hosts running with the above two conditions should be aware that the 539 panic threshold does not protect them from attacks. The recommended 540 and natural solution is not to run hosts with these conditions. 541 Specifically, only ignore the panic threshold in cold-start 542 situations if sufficient oversight and checking is in place to make 543 sure that this is appropriate. 545 As an alternative, the following steps could be taken to mitigate the 546 risk of attack. 548 o Monitor NTP system log to detect when the NTP daemon has quit due 549 to a panic event, as this could be a sign of an attack. 551 o Request manual intervention when a timestep larger than the panic 552 threshold is detected. 554 o Prevent the NTP daemon from taking time steps that set the clock 555 to a time earlier than the compile date of the NTP daemon. 557 o Add "minsane" and "minclock" parameters to the ntp.conf file so 558 ntpd waits until "enough" trusted sources of time agree on the 559 correct time. 561 6.3. Detection of Attacks Through Monitoring 563 Users should monitor their NTP instances to detect attacks. Many 564 known attacks on NTP have particular signatures. Common attack 565 signatures include: 567 1. "Bogus packets" - A packet whose origin timestamp does not match 568 the value that expected by the client. 570 2. "Zero origin packet" - A packet with an origin timestamp set to 571 zero [CVE-2015-8138]. 573 3. A packet with an invalid cryptographic MAC [CCR16]. 575 The observation of many such packets could indicate that the client 576 is under attack. 578 Also, Kiss-o'-Death (KoD) packets can be used in denial of service 579 attacks. Thus, the observation of even just one KoD packet with a 580 high poll value could be sign that the client is under attack. See 581 Section 6.4 for more information. 583 6.4. KISS Packets 585 The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a 586 server can tell a misbehaving client to "back off" its query rate. 587 It is important for all NTP devices to respect these packets and back 588 off when asked to do so by a server. It is even more important for 589 an embedded device, which may not have exposed a control interface 590 for NTP. 592 That said, a client must only accept a KoD packet if it has a valid 593 origin timestamp. Once a RATE packet is accepted, the client should 594 increase its poll interval value (thus decreasing its polling rate) 595 up to a reasonable maximum. This maximum can vary by implementation 596 but should not exceed a poll interval value of 13 (2 hours). The 597 mechanism to determine how much to increase the poll interval value 598 is undefined in RFC 5905 [RFC5905]. If the client uses the poll 599 interval value sent by the server in the KoD packet, it must not 600 simply accept any value. Using large interval values may open a 601 vector for a denial-of-service attack that causes the client to stop 602 querying its server [NDSS16]. 604 The KoD mechanism relies on clients behaving properly in order to be 605 effective. Some clients ignore the KoD packet entirely, and other 606 poorly-implemented clients might unintentionally increase their poll 607 rate and simulate a denial of service attack. Server administrators 608 should be prepared for this and take measures outside of the NTP 609 protocol to drop packets from misbehaving clients. 611 6.5. Broadcast Mode Should Only Be Used On Trusted Networks 613 Per RFC 5905 [RFC5905], NTP's broadcast mode is authenticated using 614 symmetric key cryptography. The broadcast server and all of its 615 broadcast clients share a symmetric cryptographic key, and the 616 broadcast server uses this key to append a message authentication 617 code (MAC) to the broadcast packets it sends. 619 Importantly, all broadcast clients that listen to this server must 620 know the cryptographic key. This mean that any client can use this 621 key to send valid broadcast messages that look like they come from 622 the broadcast server. Thus, a rogue broadcast client can use its 623 knowledge of this key to attack the other broadcast clients. 625 For this reason, an NTP broadcast server and all its client must 626 trust each other. Broadcast mode should only be run from within a 627 trusted network. 629 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 630 column, a comma-separated list of IPs that are allowed to serve time. 631 Use this feature. Note, however, that an adversarial client that 632 knows the symmetric broadcast key could still easily spoof its source 633 IP to an IP that is allowed to serve time. (This is easy to do 634 because the origin timestamp on broadcast mode packets is not 635 validated by the client. By contrast, client/server and symmetric 636 modes do require origin timestamp validation, making it more 637 difficult to spoof packets [CCR16]. 639 6.6. Symmetric Mode Should Only Be Used With Trusted Peers 641 In symmetric mode, two peers Alice and Bob can both push and pull 642 synchronization to and from each other using either ephemeral 643 symmetric passive (mode 2) or persistent symmetric active (NTP mode 644 1) packets. The persistent association is preconfigured and 645 initiated at the active peer but not preconfigured at the passive 646 peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob 647 mobilizes a new ephemeral association if he does not have one 648 already. This is a security risk for Bob because an arbitrary 649 attacker can attempt to change Bob's time by asking Bob to become its 650 symmetric passive peer. 652 For this reason, a host (Bob) should only allow symmetric passive 653 associations to be established with trusted peers. Specifically, Bob 654 should require each of its symmetric passive association to be 655 cryptographically authenticated. Each symmetric passive association 656 should be authenticated under a different cryptographic key. 658 The use of a different cryptographic key per peer prevents a Sybil 659 attack, where a single malicious peer uses the same cryptographic key 660 to set up multiple symmetric associations a target, and thus bias the 661 results of the target's Byzantine fault tolerant peer selection 662 algorithms. 664 Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th 665 column, a comma-separated list of IPs that are allowed to serve time. 666 Use this feature. 668 7. NTP in Embedded Devices 670 Readers of this BCP already understand how important accurate time is 671 for network computing. And as computing becomes more ubiquitous, 672 there will be many small "Internet of Things" devices that require 673 accurate time. These embedded devices may not have a traditional 674 user interface, but if they connect to the Internet they will be 675 subject to the same security threats as traditional deployments. 677 7.1. Updating Embedded Devices 679 Vendors of embedded devices have a special responsibility to pay 680 attention to the current state of NTP bugs and security issues, 681 because their customers don't have the ability to update their NTP 682 implementation on their own. Those devices may have a single 683 firmware upgrade, provided by the manufacturer, that updates all 684 capabilities at once. This means that the vendor assumes the 685 responsibility of making sure their devices have the latest NTP 686 updates applied. 688 This should also include the ability to update any NTP server 689 addresses on these devices. 691 There is a catalog of NTP server abuse incidents, some of which 692 involve embedded devices, on the Wikipedia page for NTP Server Misuse 693 and Abuse [9]. 695 7.2. Server configuration 697 Vendors of embedded devices that need time synchronization should 698 also carefully consider where they get their time from. There are 699 several public-facing NTP servers available, but they may not be 700 prepared to service requests from thousands of new devices on the 701 Internet. 703 Vendors are encouraged to invest resources into providing their own 704 time servers for their devices to connect to. 706 7.2.1. Get a vendor subdomain for pool.ntp.org 708 The NTP Pool Project offers a program where vendors can obtain their 709 own subdomain that is part of the NTP Pool. This offers vendors the 710 ability to safely make use of the time distributed by the Pool for 711 their devices. Vendors are encouraged to support the pool if they 712 participate. For more information, visit http://www.pool.ntp.org/en/ 713 vendors.html [10] . 715 8. NTP over Anycast 717 Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 718 [RFC7094]). With anycast, a single IP address is assigned to 719 multiple interfaces, and routers direct packets to the closest active 720 interface. 722 Anycast is often used for Internet services at known IP addresses, 723 such as DNS. Anycast can also be used in large organizations to 724 simplify configuration of a large number of NTP clients. Each client 725 can be configured with the same NTP server IP address, and a pool of 726 anycast servers can be deployed to service those requests. New 727 servers can be added to or taken from the pool, and other than a 728 temporary loss of service while a server is taken down, these 729 additions can be transparent to the clients. 731 NOTE WELL: Using a single anycast address for NTP should be done with 732 care. It means each client will likely use a single time server 733 source. A key element of a robust NTP deployment is each client 734 using multiple sources of time. With multiple time sources, a client 735 will analyze the various time sources, selecting good ones, and 736 disregarding poor ones. If a single Anycast address is used, this 737 analysis will not happen. 739 If clients are connected to an NTP server via anycast, the client 740 does not know which particular server they are connected to. As 741 anycast servers may arbitrarily enter and leave the network, the 742 server a particular client is connected to may change. This may 743 cause a small shift in time from the perspective of the client when 744 the server it is connected to changes. It is recommended that 745 anycast only be deployed in environments where these small shifts can 746 be tolerated. 748 Configuration of an anycast interface is independent of NTP. Clients 749 will always connect to the closest server, even if that server is 750 having NTP issues. It is recommended that anycast NTP 751 implementations have an independent method of monitoring the 752 performance of NTP on a server. If the server is not performing to 753 specification, it should remove itself from the Anycast network. It 754 is also recommended that each Anycast NTP server have at least one 755 Unicast interface, so its performance can be checked independently of 756 the anycast routing scheme. 758 One useful application in large networks is to use a hybrid unicast/ 759 anycast approach. Stratum 1 NTP servers can be deployed with unicast 760 interfaces at several sites. Each site may have several Stratum 2 761 servers with two ethernet interfaces. One interface has a unique 762 unicast IP address. The second has an anycast IP interface (with a 763 shared IP address per location). The unicast interfaces can be used 764 to obtain time from the Stratum 1 servers globally (and perhaps peer 765 with the other Stratum 2 servers at their site). Clients at each 766 site can be configured to use the shared anycast address for their 767 site, simplifying their configuration. Keeping the anycast routing 768 restricted on a per-site basis will minimize the disruption at the 769 client if its closest anycast server changes. Each Stratum 2 server 770 can be uniquely identified on their unicast interface, to make 771 monitoring easier. 773 9. Acknowledgements 775 The authors wish to acknowledge the contributions of Sue Graves, 776 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 777 Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, and 778 Robert Nagy. 780 10. IANA Considerations 782 This memo includes no request to IANA. 784 11. Security Considerations 786 Time is a fundamental component of security on the internet. 787 Credentials and certificates can expire. Logins and other forms of 788 access can be revoked after a period of time, or at a scheduled time. 789 And some applications may assume that system time cannot be changed 790 and is always monotonic, and vulnerabilites may be exposed if a time 791 in the past is forced into a system. Therefore, any system 792 adminstrator concerned with security should be concerned with how the 793 current time gets into their system. 795 [NTSFORNTP] is an Internet-Draft that specifies the Network Time 796 Security (NTS) mechanism and applies it specifically to NTP. Readers 797 are encouraged to check the status of the draft, and make use of the 798 methods it describes. 800 12. References 802 12.1. Normative References 804 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 805 Specification, Implementation and Analysis", RFC 1305, 806 DOI 10.17487/RFC1305, March 1992, 807 . 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, 811 DOI 10.17487/RFC2119, March 1997, 812 . 814 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 815 Defeating Denial of Service Attacks which employ IP Source 816 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 817 May 2000, . 819 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 820 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 821 December 2006, . 823 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 824 "Network Time Protocol Version 4: Protocol and Algorithms 825 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 826 . 828 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 829 "Architectural Considerations of IP Anycast", RFC 7094, 830 DOI 10.17487/RFC7094, January 2014, 831 . 833 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 834 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 835 October 2014, . 837 12.2. Informative References 839 [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's 840 Authenticated Broadcast Mode", SIGCOMM Computer 841 Communications Review (CCR) , 2016. 843 [CTRLMSG] Mills, D. and B. Haberman, "Control Messages Protocol for 844 Use with Network Time Protocol Version 4", draft-ietf-ntp- 845 mode-6-cmds-05 (work in progress), March 2018. 847 [CVE-2015-8138] 848 Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL 849 ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 850 . 852 [CVE-2015-8139] 853 Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC 854 ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 855 . 857 [CVE-2016-1548] 858 Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode 859 to Interleaved", 2016, 860 . 863 [MILLS2006] 864 Mills, D., "Computer network time synchronization: the 865 Network Time Protocol", CRC Press , 2006. 867 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 868 "Attacking the Network Time Protocol", NDSS'16, San Diego, 869 CA. , 2016, . 871 [NTSFORNTP] 872 Sibold, D., Roettger, S., and K. Teichel, "Using the 873 Network Time Security Specification to Secure the Network 874 Time Protocol", draft-ietf-ntp-using-nts-for-ntp-12 (work 875 in progress), July 2018. 877 12.3. URIs 879 [1] http://www.bcp38.info 881 [2] http://www.pool.ntp.org/en/use.html 883 [3] http://www.pool.ntp.org/en/join.html 885 [4] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 887 [5] https://www.iers.org/IERS/EN/Publications/Bulletins/ 888 bulletins.html 890 [6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 892 [7] https://www.ietf.org/timezones/data/leap-seconds.list 894 [8] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html 896 [9] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 898 [10] http://www.pool.ntp.org/en/vendors.html 900 [11] http://www.ntp.org/downloads.html 902 [12] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno 904 [13] https://support.ntp.org/bin/view/Support/ConfiguringNTP 906 Appendix A. Implementation Specific Information 908 This appendix procides information that is specific to various 909 implementation of RFC 5905. 911 A.1. NTP Implementation by the Network Time Foundation 913 The Network Time Foundation (NTF) provides the reference 914 implementation of NTP, well-known under the name "ntpd". It is 915 actively maintained and developed by NTF's NTP Project, with help 916 from volunteers and NTF's supporters. This NTP software can be 917 downloaded from ntp.org [11]. 919 A.1.1. Use enough time sources 921 In addition to the recommendation given in Section Section 4.1 the 922 ntpd implementation provides the 'pool' directive. Starting with 923 ntp-4.2.6, this directive will spin up "enough" associations to 924 provide robust time service, and will disconnect poor servers and add 925 in new servers as-needed. If you have good reason, you may use the 926 'minclock' and 'maxclock' options of the 'tos' command to override 927 the default values of how many servers are discovered through the 928 'pool' directive. 930 A.1.2. NTP Control and Facility Messages 932 In addition to NTP Control Messages the ntpd implementation also 933 offers the mode 7 commands for monitoring and configuration. 935 If Mode 7 has been explicitly enabled to be used for more than basic 936 monitoring it should be limited to authenticated sessions that 937 provide a 'requestkey'. 939 As mentioned above, there are two general ways to use Mode 6 and Mode 940 7 requests. One way is to query ntpd for information, and this mode 941 can be disabled with: 943 restrict ... noquery 945 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 946 behavior. Modification of ntpd's configuration requires an 947 authenticated session BY default. If no authentication keys have 948 been specified no modifications can be made. For additional 949 protection, the ability to perform these modifications can be 950 controlled with: 952 restrict ... nomodify 953 Users can prevent their NTP servers from considering query/ 954 configuration traffic by default by adding the following to their 955 ntp.conf file: 957 restrict default -4 nomodify notrap nopeer noquery 959 restrict default -6 nomodify notrap nopeer noquery 961 restrict source nomodify notrap noquery 962 # nopeer is OK if you don't use the 'pool' directive 964 A.1.3. Monitoring 966 The reference implementation of NTP allows remote monitoring. Access 967 to this service is generally controlled by the "noquery" directive in 968 NTP's configuration file (ntp.conf) via a "restrict" statement. The 969 syntax reads: 971 restrict address mask address_mask noquery 973 If a system is using broadcast mode and is running ntp-4.2.8p6 or 974 later, use the 4th field of the ntp.keys file to specify the IPs of 975 machines that are allowed to serve time to the group. 977 A.1.4. Leap Second File 979 The use of leap second files requires ntpd 4.2.6 or later. After 980 fetching the leap seconds file onto the server, add this line to 981 ntpd.conf to apply and use the file: 983 leapfile "/path/to your/leap-file" 985 You may need to restart ntpd to apply this change. 987 ntpd servers with a manually configured leap second file will ignore 988 leap second information broadcast from upstream NTP servers until the 989 leap second file expires. If no valid leap second file is available 990 then a leap second notification from an attached reference clock is 991 always accepted by ntpd. 993 If no valid leap second file is available, a leap second notification 994 may be accepted from upstream NTP servers. As of ntp-4.2.6, a 995 majority of servers must provide the notification before it is 996 accepted. Before 4.2.6, a leap second notification would be accepted 997 if a single upstream server of a group of configured servers provided 998 a leap second notification. This would lead to misbehavior if single 999 NTP servers sent an invalid leap second warning, e.g. due to a faulty 1000 GPS receiver in one server, but this behavior was once chosen because 1001 in the "early days" there was a greater chance that leap second 1002 information would be available from a very limited number of sources. 1004 A.1.5. Leap Smearing 1006 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in 1007 response to CLIENT requests. Support for leap smearing is not 1008 configured by default and must be added at compile time. In 1009 addition, no leap smearing will occur unless a leap smear interval is 1010 specified in ntpd.conf . For more information, refer to 1011 http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [12]. 1013 A.1.6. Configuring ntpd 1015 See https://support.ntp.org/bin/view/Support/ConfiguringNTP [13] for 1016 additional information on configuring ntpd. 1018 A.1.7. Pre-Shared Keys 1020 Each communication partner must add the keyid information to their 1021 key file in the form: 1023 keyid label key 1025 An ntpd client establishes a protected association by appending the 1026 option "key keyid" to the server statement in ntp.conf: 1028 server address key keyid 1030 A key is deemed trusted when its keyid is added to the list of 1031 trusted keys by the "trustedkey" statement in ntp.conf. 1033 trustedkey keyid_1 keyid_2 ... keyid_n 1035 Authors' Addresses 1037 Denis Reilly (editor) 1038 Spectracom 1039 1565 Jefferson Road, Suite 460 1040 Rochester, NY 14623 1041 US 1043 Email: denis.reilly@spectracom.orolia.com 1044 Harlan Stenn 1045 Network Time Foundation 1046 P.O. Box 918 1047 Talent, OR 97540 1048 US 1050 Email: stenn@nwtime.org 1052 Dieter Sibold 1053 Physikalisch-Technische Bundesanstalt 1054 Bundesallee 100 1055 Braunschweig D-38116 1056 Germany 1058 Phone: +49-(0)531-592-8420 1059 Fax: +49-531-592-698420 1060 Email: dieter.sibold@ptb.de