idnits 2.17.1 draft-ietf-ntp-bcp-01.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 2 instances 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 (October 4, 2016) is 2754 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 875 -- Looks like a reference, but probably isn't: '2' on line 877 -- Looks like a reference, but probably isn't: '3' on line 879 -- Looks like a reference, but probably isn't: '5' on line 881 -- Looks like a reference, but probably isn't: '6' on line 883 -- Looks like a reference, but probably isn't: '7' on line 885 -- Looks like a reference, but probably isn't: '8' on line 888 -- Looks like a reference, but probably isn't: '9' on line 890 -- Looks like a reference, but probably isn't: '12' on line 892 ** Downref: Normative reference to an Informational RFC: RFC 7094 ** Downref: Normative reference to an Informational RFC: RFC 7384 == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-06 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 Corporation 4 Intended status: Best Current Practice H. Stenn 5 Expires: April 7, 2017 Network Time Foundation 6 D. Sibold 7 PTB 8 October 4, 2016 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-01 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 http://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 April 7, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 (http://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. Mode 6 and 7 . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 64 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 8 65 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9 66 4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 10 67 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10 68 5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10 69 5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.3. Network Time Security . . . . . . . . . . . . . . . . . . 11 71 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12 72 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 12 73 6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12 74 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 13 75 6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 14 76 6.5. 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. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 15 80 7.3. Server configuration . . . . . . . . . . . . . . . . . . 16 81 7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 16 82 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 12.2. Informative References . . . . . . . . . . . . . . . . . 18 89 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 NTP Version 4 (NTPv4) has been widely used since its publication as 95 RFC 5905 [RFC5905]. This documentation is a collection of Best 96 Practices from across the NTP community. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. Keeping NTP up to date 106 Many network security mechanisms rely on time as part of their 107 operation. If an attacker can spoof the time, they may be able to 108 bypass or neutralize other security elements. For example, incorrect 109 time can disrupt the ability to reconcile logfile entries on the 110 affected system with events on other systems. The best way to 111 protect computers and networks against undefined behavior and 112 security threats related to time is to keep their NTP implementations 113 current. 115 There are always new ideas about security on the Internet, and an 116 application which is secure today could be insecure tomorrow once an 117 unknown bug (or a known behavior) is exploited in the right way. 118 Even our definition of what is secure has evolved over the years, so 119 code which was considered secure when it was written can be 120 considered insecure after some time. By keeping NTP implementations 121 current, network operators can make sure that older behaviors are not 122 exploited. 124 Thousands of individual bugs have been found and fixed in the NTP 125 Project's ntpd since the first NTPv4 release in 1997. Each version 126 release contains at least a few bug fixes. The best way to stay in 127 front of these issues is to keep your NTP implementation current. 129 There are multiple versions of the NTP protocol in use, and multiple 130 implementations in use, on many different platforms. It is 131 recommended that NTP users actively monitor wherever they get their 132 software to find out if their versions are vulnerable to any known 133 attacks, and deploy updates containing security fixes as soon as 134 practical. 136 The reference implementation of NTP Version 4 from Network Time 137 Foundation (NTF) continues to be actively maintained and developed by 138 NTF's NTP Project, with help from volunteers and NTF's supporters. 140 The NTP software can be downloaded from ntp.org [1] and also from 141 NTF's github page [2]. 143 3. General Network Security Best Practices 145 3.1. BCP 38 147 Many network attacks rely on modifying the IP source address of a 148 packet to point to a different IP address than the computer which 149 originated it. This modification/abuse vector has been known for 150 quite some time, and BCP 38 [RFC2827] was approved in 2000 to address 151 this. BCP 38 [RFC2827] calls for filtering outgoing and incoming 152 traffic to make sure that the source and destination IP addresses are 153 consistent with the expected flow of traffic on each network 154 interface. It is recommended that all networks (and ISP's of any 155 size) implement this. If a machine on a network is sending out 156 packets claiming to be from an address that is not on that network, 157 this could be the first indication that there is a machine that has 158 been compromised, and is being used abusively. If packets are 159 arriving on an external interface with a source address that should 160 only be seen on an internal network, that's a strong indication that 161 an attacker is trying to inject spoofed packets into the network. 162 More information is available at the BCP38 Info page [3] . 164 4. NTP Configuration Best Practices 166 These Best Practices, while based on the ntpd reference 167 implementation maintained by the Network Time Foundation, may be 168 applicable to other implementations as well. 170 4.1. Use enough time sources 172 ntpd takes the available sources of time and submits their timing 173 data to intersection and clustering algorithms, looking for the best 174 idea of the correct time. 176 o If there is only 1 source of time, the answer is obvious. It may 177 not be a good source of time, but it's the only one. 179 o If there are 2 sources of time and they agree well enough, that's 180 good. But if they don't, then ntpd has no way to know which 181 source to believe. 183 o If there are 3 sources of time, you can tolerate one of those 184 sources becoming unreachable or unusable. But at that point, we 185 are back down to 2 sources. 187 o 4 sources of time is better. If one of these sources develops a 188 problem there are still 3 others. 190 But even with 4 or more sources of time, systemic issues can happen. 191 During the leap second of June of 2015, several operators implemented 192 leap smearing while others did not, and many NTP end nodes became 193 very confused. See Section 4.6.1 for more information. 195 Starting with ntp-4.2.6, the 'pool' directive will spin up "enough" 196 associations to provide robust time service, and will disconnect poor 197 servers and add in new servers as-needed. 199 Monitor your ntpd instances. If your times sources do not generally 200 agree, find out why and either correct the problems or stop using 201 defective servers. See Section 4.4 for more information. 203 4.2. Use a diversity of Reference Clocks 205 When using servers with attached hardware reference clocks, it is 206 recommended that several different types of reference clocks be used. 207 Having a diversity of sources means that any one issue is less likely 208 to cause a service interruption. 210 Are all clocks on a network from the same vendor? They may have the 211 same bugs. Are they using the same base chipset, regardless of 212 whether or not the finished products are from different vendors? Are 213 they all running the same version of firmware? Chipset and firmware 214 bugs can happen, but is often more difficult to diagnose than a 215 standard software bug. 217 A systemic problem with time from any satellite navigation service is 218 possible and has happened. Sunspot activity can render satellite or 219 radio-based time source unusable. If the time on your network must 220 be correct close to 100% of the time, then even if you are using a 221 satellite-based system, you must plan for those rare instances when 222 the system is unavailable (or wrong!). 224 4.3. Mode 6 and 7 226 NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit 227 monitoring and optional authenticated control of ntpd and its 228 configuration. Used properly, these facilities provide vital 229 debugging and performance information and control. Used improperly, 230 these facilities can be an abuse vector. 232 Mode 7 queries have been disabled by default in ntpd since 4.2.7p230, 233 released on 2011/11/01. Do not enable Mode 7 unless there is a 234 compelling reason to do so. 236 The ability to use Mode 6 beyond its basic monitoring capabilities 237 can be limited to authenticated sessions that provide a 'controlkey', 238 and similarly, if Mode 7 has been explicitly enabled its use for more 239 than basic monitoring can be limited to authenticated sessions that 240 provide a 'requestkey'. 242 Older versions of the reference implementation of NTP could be abused 243 to participate in high-bandwidth DDoS attacks, if the above 244 restrictions are not applied. Starting with ntp-4.2.7p26, released 245 in April of 2010, ntpd requires the use of a nonce before replying 246 with potentially large response packets. 248 As mentioned above, there are two general ways to use Mode 6 and Mode 249 7 requests. One way is to query ntpd for information, and this mode 250 can be disabled with: 252 restrict ... noquery 254 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 255 behavior. Modification of ntpd ordinarily requires an authenticated 256 session. By default, if no authentication keys have been specified 257 no modifications can be made. For additional protection, the ability 258 to perform these modifications can be controlled with: 260 restrict ... nomodify 262 Users can prevent their NTP servers from participating by adding the 263 following to their ntp.conf file: 265 restrict default -4 nomodify notrap nopeer noquery 267 restrict default -6 nomodify notrap nopeer noquery 269 restrict source nomodify notrap noquery 270 # nopeer is OK if you don't use the 'pool' directive 272 4.4. Monitoring 274 The reference implementation of NTP allows remote monitoring. The 275 access to this service is controlled by the restrict statement in 276 NTP's configuration file (ntp.conf). The syntax reads: 278 restrict address mask address_mask nomodify 280 Monitor ntpd instances so machines that are "out of sync" can be 281 quickly identified. Monitor system logs for messages from ntpd so 282 abuse attempts can be quickly identified. 284 If a system starts getting unexpected time replies from its time 285 servers, that can be an indication that the IP address of the server 286 is being forged in requests to that time server, and these abusers 287 are trying to convince your time servers to stop serving time to the 288 system. 290 If a system is a broadcast client and its syslog shows that it is 291 receiving "early" time messages from its server, that is an 292 indication that somebody may be forging packets from a broadcast 293 server. 295 If a server's syslog shows messages that indicates it is receiving 296 timestamps that are earlier than the current system time, then either 297 the system clock is unusually fast or somebody is trying to launch a 298 replay attack against that server. 300 If a system is using broadcast mode and is running ntp-4.2.8p6 or 301 later, use the 4th field of the ntp.keys file to identify the IPs of 302 machines that are allowed to serve time to the group. 304 4.5. Using Pool Servers 306 It only takes a small amount of bandwidth and system resources to 307 synchronize one NTP client, but NTP servers that can service tens of 308 thousands of clients take more resources to run. Users who want to 309 synchronize their computers should only synchronize to servers that 310 they have permission to use. 312 The NTP pool project is a collection of volunteers who have donated 313 their computing and bandwidth resources to provide time on the 314 Internet for free. The time is generally of good quality, but comes 315 with no guarantee whatsoever. If you are interested in using the 316 pool, please review their instructions at http://www.pool.ntp.org/en/ 317 use.html . 319 If you want to synchronize many computers using the pool, consider 320 running your own NTP servers, synchronizing them to the pool, and 321 synchronizing your clients to your in-house NTP servers. This 322 reduces the load on the pool. 324 If you would like to contribute a server with a static IP address and 325 a permanent Internet conenction to the pool, please consult the 326 instructions at pool.ntp.org [5] . 328 4.6. Leap Second Handling 330 UTC is kept in agreement with the astronomical time UT1 [6] to witin 331 +0.9 second (in absolute value) by the insertion of leap seconds. 332 UTC is an atomic time scale whereas UT1 is based on the rotational 333 rate of the earth. Leap seconds are not introduced at a fixed rate. 334 They are announced when necessary to keep UTC and UT1 aligned by the 335 IERS (International Earth rotation and Reference systems Service) in 336 its Bulletin C [7]. 338 NTP time is based on the UTC timescale, and the protocol has the 339 capability to broadcast leap second information. Some GNSS systems 340 (like GPS) or radio transmitters (like DCF77) broadcast leap second 341 information, so if you have a Stratum-1 server synced to GNSS (or you 342 are synced to a lower stratum server that is ultimately synced to 343 GNSS), you will get advance notification of impending leap seconds 344 automatically. 346 Since the length of the UT1 day is slowly increasing [8], all leap 347 seconds that have been introduced since the practice started in 1972 348 have been "positive" leap seconds, where a second is added to UTC. 349 NTP also supports a "negative" leap second, where a second is removed 350 from UTC, should that ever become necessary. 352 While earlier versions of NTP contained some ambiguity regarding when 353 leap seconds could occur, RFC 5905 is clear that leap seconds are 354 processed at the end of a month. If an upstream server is 355 broadcasting that a leap second is pending, RFC5905-compliant servers 356 should apply it at the end of the last minute of the last day of the 357 month. 359 The IETF maintains a leap second list [9] for NTP users who are not 360 receiving leap second information through an automatic source. The 361 use of leap second files requires ntpd 4.2.6 or later. After 362 fetching the leap seconds file onto the server, add this line to 363 ntpd.conf to apply the file: 365 leapfile "/path/to your/leap-file" 367 You will need to restart to apply the changes. 369 Files are also available from other sources: 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 375 IERS (announces leap seconds): 376 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 378 ntpd servers with a manually configured leap second file will ignore 379 leap second information broadcast from upstream NTP servers until the 380 leap second file expires. If no valid leap second file is available 381 then a leap second notification from an attached reference clock is 382 always accepted by ntpd. 384 If no valid leap second file is available, a leap second notification 385 may be accepted from upstream NTP servers. As of ntpd 4.2.6, a 386 majority of servers must provide the notification before it is 387 accepted. Before 4.2.6, a leap second notification would be accepted 388 if only a single upstream server of a group of configured servers 389 provided a leap second notification. This would lead to misbehavior 390 if single NTP servers sent an invalid leap second warning, e.g. due 391 to a faulty GPS receiver in one server. 393 4.6.1. Leap Smearing 395 Some NTP installations may instead make use of a technique called 396 "Leap Smearing". With this method, instead of introducing an extra 397 second (or eliminating a second), NTP time will be slewed in small 398 increments over a comparably large window of time (called the smear 399 interval) around the leap second event. The smear interval should be 400 large enough to make the rate that the time is slewed small, so that 401 clients will follow the smeared time without objecting. (86400s, 402 which is 1 day, has been used sucessfully.) During the adjustment 403 window, all the NTP clients' times may be offset from UTC by as much 404 as a full second, depending on the implementation. But at least all 405 clients will agree on what time they think it is! 407 The purpose of Leap Smearing is to enable software that doesn't deal 408 with the leap second event properly to function correctly, at the 409 expense of fidelity to UTC during the smear window. During a 410 standard leap second event, that minute will have 61 (or possibly 59) 411 seconds in it, and some applications (and even some OS's) are known 412 to have problems with that. 414 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47. 415 Support is not configured by default and must be added at compile 416 time. In addition, no leap smearing will occur unless a leap smear 417 interval is specified in ntpd.conf . For more information, refer to 418 http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno . 420 Clients that are connected to leap smearing servers must never apply 421 the "standard" NTP leap second handling. So if they are using ntpd, 422 these clients must never have a leap second file loaded, and the 423 smearing servers must never advertise a leap second is pending. 425 Leap Smearing must not be used for public-facing NTP servers, as they 426 will disagree with non-smearing servers (as well as UTC) during the 427 leap smear interval. However, be aware that some public-facing 428 servers may be configured this way anyway in spite of this guidance. 430 System Administrators are advised to be aware of impending leap 431 seconds and how the servers (inside and outside their organization) 432 they are using deal with them. Individual clients must never be 433 configured to use a mixture of smeared and non-smeared servers. 435 4.7. Configuring ntpd 437 See https://support.ntp.org/bin/view/Support/ConfiguringNTP for 438 additional information on configuring ntpd. 440 5. NTP Security Mechanisms 442 In the standard configuration NTP packets are exchanged unprotected 443 between client and server. An adversary that is able to become a 444 Man-In-The-Middle is therefore able to drop, replay or modify the 445 content of the NTP packet, which leads to degradation of the time 446 synchronization or the transmission of false time information. A 447 profound threat analysis for time synchronization protocols are given 448 in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms 449 to protect authenticity and integrity of the NTP packets. Both 450 measures protect the NTP packet by means of a Message Authentication 451 Code (MAC). Neither of them encrypts the NTP's payload, because it 452 is not considered to be confidential. 454 5.1. Pre-Shared Key Approach 456 This approach applies a symmetric key for the calculation of the MAC, 457 which protects authenticity and integrity of the exchanged packets 458 for a association. NTP does not provide a mechanism for the exchange 459 of the keys between the associated nodes. Therefore, for each 460 association, keys have to be exchanged securely by external means. 461 It is recommended that each association is protected by its own 462 unique key. NTP does not provide a mechanism to automatically 463 refresh the applied keys. It is therefore recommended that the 464 participants periodically agree on a fresh key. The calculation of 465 the MAC may always be based on an MD5 hash. If the NTP daemon is 466 built against an OpenSSL library, NTP can also base the calculation 467 of the MAC upon the SHA-1 or any other digest algorithm supported by 468 each side's OpenSSL library. 470 To use this approach the communication partners have to exchange the 471 key, which consists of a keyid with a value between 1 and 65534, 472 inclusive, and a label which indicates the chosen digest algorithm. 473 Each communication partner adds this information to their key file in 474 the form: 476 keyid label key 478 The key file contains the key in clear text. Therefore it should 479 only be readable by the NTP process. Different keys are added line 480 by line to the key file. 482 A NTP client establishes a protected association by appending the 483 option "key keyid" to the server statement in the NTP configuration 484 file: 486 server address key keyid 488 Note that the NTP process has to trust the applied key. An NTP 489 process explicitly has to add each key it want to trust to a list of 490 trusted keys by the "trustedkey" statement in the NTP configuration 491 file. 493 trustedkey keyid_1 keyid_2 ... keyid_n 495 5.2. Autokey 497 Autokey was designed in 2003 to provide a means for clients to 498 authenticate servers. By 2011, security researchers had identified 499 computational areas in the Autokey protocol that, while secure at the 500 time of its original design, were no longer secure. 502 We recommend that Autokey NOT BE USED. Know that as of the fall of 503 2011, a common(?) laptop computer could crack the security cookie 504 used in the Autokey protocol in 30 minutes' time. If you must use 505 Autokey, know that your session keys should be set to expire in under 506 30 minutes' time. 508 5.3. Network Time Security 510 Work has begun on an enhanced replacement for Autokey, which is 511 called Network Time Security (NTS) [NTS]. NTS was published in the 512 summer of 2013. As of October 2016, this effort was at draft #15, 513 and about to begin 'final call'. The first unicast implementation of 514 NTS was started in the summer of 2015 and is expected to be released 515 in 2016. 517 6. NTP Security Best Practices 519 6.1. Minimizing Information Leakage 521 The base NTP packet leaks important information (including reference 522 ID and reference time) that can be used in attacks [NDSS16], 523 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 524 information by sending mode 3 queries to a target system and 525 inspecting the fields in the mode 4 response packet. NTP control 526 queries also leak important information (including reference ID, 527 expected origin timestamp, etc) that can be used in attacks 528 [CVE-2015-8139]. A remote attacker can learn this information by 529 sending control queries to a target system and inspecting the 530 response. 532 As such, access control should be used to limit the exposure of this 533 information to third parties. 535 All hosts should only respond to NTP control queries from authorized 536 parties. One way to do this is to only allow control queries from 537 authorized IP addresses. 539 A host that is not supposed to act as an NTP server that provides 540 timing information to other hosts should additionally drop incoming 541 mode 3 timing queries. 543 An "end host" is host that is using NTP solely for the purpose of 544 adjusting its own system time. Such a host is not expected to 545 provide time to other hosts, and relies exclusively on NTP's basic 546 mode to take time from a set of servers. (That is, the host sends 547 mode 3 queries to its servers and receives mode 4 responses from 548 these servers containing timing information.) To minimize 549 information leakage, end hosts should drop all incoming NTP packets 550 except mode 4 response packets that come from its configured servers. 552 6.2. Avoiding Daemon Restart Attacks 554 [RFC5905] says NTP clients should not accept time shifts greater than 555 the panic threshold. Specifically, RFC5905 says "PANIC means the 556 offset is greater than the panic threshold PANICT (1000 s) and SHOULD 557 cause the program to exit with a diagnostic message to the system 558 log. 560 However, this behavior can be exploited by attackers [NDSS16], when 561 the following two conditions hold: 563 1. The operating system automatically restarts the NTP daemon when 564 it quits. (Modern *NIX operating systems are replacing 565 traditional init systems with process supervisors, such as 566 systemd, which can be configured to automatically restart any 567 daemons that quit. This behavior is the default in CoreOS and 568 Arch Linux. It is likely to become the default behavior in other 569 systems as they migrate legacy init scripts to systemd.) 571 2. The NTP daemon ignores the panic threshold when it is restarted. 572 (This is sometimes called the -g option.) 574 In such cases, the attacker can send the target an offset that 575 exceeds the panic threshold, causing the client to quit. Then, when 576 the client restarts, it ignores the panic threshold and accepts the 577 attacker's large offset. 579 Hosts running with the above two conditions should be aware that the 580 panic threshold does not protect them from attacks. A natural 581 solution is not to run hosts with these conditions. 583 As an alternative, the following steps could be taken to mitigate the 584 risk of attack. 586 o Monitor NTP system log to detect when the NTP daemon has quit due 587 to a panic event, as this could be a sign of an attack. 589 o Request manual intervention when a timestep larger than the panic 590 threshold is detected. 592 o Prevent the NTP daemon from taking time steps that set the clock 593 to a time earlier than the compile date of the NTP daemon. 595 o Modify the NTP daemon so that it "hangs" (ie does not quit, but 596 just waits for a better timing samples but does not modify the 597 local clock) when it receives a large offset. 599 6.3. Detection of Attacks Through Monitoring 601 Users should monitor their NTP instances to detect attacks. Many 602 known attacks on NTP have particular signatures. Common attack 603 signatures include: 605 1. "Bogus packets" - A packet whose origin timestamp does not match 606 the value that expected by the client. 608 2. "Zero origin packet" - A packet with a origin timestamp set to 609 zero [CVE-2015-8138]. 611 3. A packet with an invalid cryptographic MAC [CCR16]. 613 The observation of many such packets could indicate that the client 614 is under attack. 616 Also, Kiss-o'-Death (KoD) packets can be used in denial of service 617 attacks. Thus, the observation of even just one KoD packet with a 618 high poll value (e.g. poll>10) could be sign that the client is under 619 attack. 621 6.4. Broadcast Mode Should Only Be Used On Trusted Networks 623 Per [RFC5905], NTP's broadcast mode is authenticated using symmetric 624 key cryptography. The broadcast server and all of its broadcast 625 clients share a symmetric cryptographic key, and the broadcast server 626 uses this key to append a message authentication code (MAC) to the 627 broadcast packets it sends. 629 Importantly, all broadcast clients that listen to this server must 630 know the cryptographic key. This mean that any client can use this 631 key to send valid broadcast messages that look like they come from 632 the broadcast server. Thus, a rogue broadcast client can use its 633 knowledge of this key to attack the other broadcast clients. 635 For this reason, an NTP broadcast server and all its client must 636 trust each other. Broadcast mode should only be run from within a 637 trusted network. 639 6.5. 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 arrival 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 7. NTP in Embedded Devices 666 Readers of this BCP already understand how important accurate time is 667 for network computing. And as computing becomes more ubiquitous, 668 there will be many small "Internet of Things" devices that require 669 accurate time. These embedded devices may not have a traditional 670 user interface, but if they connect to the Internet they will be 671 subject to the same security threats as traditional deployments. 673 7.1. Updating Embedded Devices 675 Vendors of embedded devices have a special responsibility to pay 676 attention to the current state of NTP bugs and security issues, 677 because their customers don't have the ability to update their NTP 678 implementation on their own. Those devices may have a single 679 firmware upgrade, provided by the manufacturer, that updates all 680 capabilities at once. This means that the vendor assumes the 681 responsibility of making sure their devices have the latest NTP 682 updates applied. 684 This should also include the ability to update the NTP server 685 address. 687 There is a catalog of NTP server abuse incidents, some of which 688 involve embedded devices, on the Wikipedia page for NTP Server Misuse 689 and Abuse [12]. 691 7.2. KISS Packets 693 The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a 694 server can tell a misbehaving client to "back off" its query rate. 695 It is important for all NTP devices to respect these packets and back 696 off when asked to do so by a server. It is even more important for 697 an embedded device, which may not have exposed a control interface 698 for NTP. 700 The KoD mechanism relies on clients behaving properly in order to be 701 effective. Some clients ignore the KoD packet entirely, and other 702 poorly-implemented clients might unintentionally increase their poll 703 rate and simulate a denial of service attack. Server administrators 704 should be prepared for this and take measures outside of the NTP 705 protocol to drop packets from misbehaving clients. 707 7.3. Server configuration 709 Vendors of embedded devices that need time synchronization should 710 also carefully consider where they get their time from. There are 711 several public-facing NTP servers available, but they may not be 712 prepared to service requests from thousands of new devices on the 713 Internet. 715 Vendors are encouraged to invest resources into providing their own 716 time servers for their devices to connect to. 718 7.3.1. Get a vendor subdomain for pool.ntp.org 720 The NTP Pool Project offers a program where vendors can obtain their 721 own subdomain that is part of the NTP Pool. This offers vendors the 722 ability to safely make use of the time distributed by the Pool for 723 their devices. Vendors are encouraged to support the pool if they 724 participate. For more information, visit http://www.pool.ntp.org/en/ 725 vendors.html . 727 8. NTP over Anycast 729 Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 730 [RFC7094]). With anycast, a single IP address is assigned to 731 multiple interfaces, and routers direct packets to the closest active 732 interface. 734 Anycast is often used for Internet services at known IP addresses, 735 such as DNS. Anycast can also be used in large organizations to 736 simplify configuration of a large number of NTP clients. Each client 737 can be configured with the same NTP server IP address, and a pool of 738 anycast servers can be deployed to service those requests. New 739 servers can be added to or taken from the pool, and other than a 740 temporary loss of service while a server is taken down, these 741 additions can be transparent to the clients. 743 If clients are connected to an NTP server via anycast, the client 744 does not know which particular server they are connected to. As 745 anycast servers may arbitrarily enter and leave the network, the 746 server a particular client is connected to may change. This may 747 cause a small shift in time from the perspective of the client when 748 the server it is connected to changes. It is recommended that 749 anycast be deployed in environments where these small shifts can be 750 tolerated. 752 Configuration of an anycast interface is independent of NTP. Clients 753 will always connect to the closest server, even if that server is 754 having NTP issues. It is recommended that anycast NTP 755 implementations have an independent method of monitoring the 756 performance of NTP on a server. If the server is not performing to 757 specification, it should remove itself from the Anycast network. It 758 is also recommended that each Anycast NTP server have at least one 759 Unicast interface, so its performance can be checked independently of 760 the anycast routing scheme. 762 One useful application in large networks is to use a hybrid unicast/ 763 anycast approach. Stratum 1 NTP servers can be deployed with unicast 764 interfaces at several sites. Each site may have several Stratum 2 765 servers with two ethernet interfaces. One interface has a unique 766 unicast IP address. The second has an anycast IP interface (with a 767 shared IP address per location). The unicast interfaces can be used 768 to obtain time from the Stratum 1 servers globally (and perhaps peer 769 with the other Stratum 2 servers at their site). Clients at each 770 site can be configured to use the shared anycast address for their 771 site, simplifying their configuration. Keeping the anycast routing 772 restricted on a per-site basis will minimize the disruption at the 773 client if its closest anycast server changes. Each Stratum 2 server 774 can be uniquely identified on their unicast interface, to make 775 monitoring easier. 777 9. Acknowledgements 779 The authors wish to acknowledge the contributions of Sue Graves, 780 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 781 Goldberg, and Martin Burnicki. 783 10. IANA Considerations 785 This memo includes no request to IANA. 787 11. Security Considerations 789 Time is a fundamental component of security on the internet. 790 Credentials and certificates can expire. Logins and other forms of 791 access can be revoked after a period of time, or at a scheduled time. 792 And some applications may assume that system time cannot be changed 793 and is always monotonic, and vulnerabilites may be exposed if a time 794 in the past is forced into a system. Therefore, any system 795 adminstrator concerned with security should be concerned with how the 796 current time gets into their system. 798 [NTS] is an Internet-Draft of a collection of methods to secure time 799 transfer over networks. [NTSFORNTP] is an Internet-Draft that 800 applies the methods in [NTS] specifically to NTP. At the time of 801 this writing, these are still drafts. Readers are encourages to 802 check the status of these drafts, and make use of the methods they 803 describe. 805 12. References 807 12.1. Normative References 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 [CVE-2015-8138] 844 Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL 845 ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 846 . 848 [CVE-2015-8139] 849 Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC 850 ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 851 . 853 [CVE-2016-1548] 854 Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode 855 to Interleaved", 2016, 856 . 859 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 860 "Attacking the Network Time Protocol", NDSS'16, San Diego, 861 CA. , 2016, . 863 [NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time 864 Security", draft-ietf-ntp-network-time-security-15 (work 865 in progress), September 2016. 867 [NTSFORNTP] 868 Sibold, D., Roettger, S., and K. Teichel, "Using the 869 Network Time Security Specification to Secure the Network 870 Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work 871 in progress), September 2016. 873 12.3. URIs 875 [1] http://www.ntp.org/downloads.html 877 [2] https://github.com/ntp-project/ntp 879 [3] http://www.bcp38.info 881 [5] http://www.pool.ntp.org/en/join.html 883 [6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 885 [7] https://www.iers.org/IERS/EN/Publications/Bulletins/ 886 bulletins.html 888 [8] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time 890 [9] https://www.ietf.org/timezones/data/leap-seconds.list 892 [12] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 894 Authors' Addresses 896 Denis Reilly (editor) 897 Spectracom Corporation 898 1565 Jefferson Road, Suite 460 899 Rochester, NY 14623 900 US 902 Email: denis.reilly@spectracom.orolia.com 904 Harlan Stenn 905 Network Time Foundation 906 P.O. Box 918 907 Talent, OR 97540 908 US 910 Email: stenn@nwtime.org 912 Dieter Sibold 913 Physikalisch-Technische Bundesanstalt 914 Bundesallee 100 915 Braunschweig D-38116 916 Germany 918 Phone: +49-(0)531-592-8420 919 Fax: +49-531-592-698420 920 Email: dieter.sibold@ptb.de