idnits 2.17.1 draft-ietf-ntp-bcp-00.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 (July 24, 2016) is 2825 days in the past. Is this intentional? 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 815 -- Looks like a reference, but probably isn't: '2' on line 817 -- Looks like a reference, but probably isn't: '4' on line 819 -- Looks like a reference, but probably isn't: '6' on line 821 -- Looks like a reference, but probably isn't: '7' on line 824 ** Downref: Normative reference to an Informational RFC: RFC 7094 ** Downref: Normative reference to an Informational RFC: RFC 7384 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Reilly 3 Internet-Draft Spectracom Corporation 4 Intended status: Best Current Practice H. Stenn 5 Expires: January 25, 2017 Network Time Foundation 6 D. Sibold 7 PTB 8 July 24, 2016 10 Network Time Protocol Best Current Practices 11 draft-ietf-ntp-bcp-00 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 January 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . 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 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 10 70 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 10 71 6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 11 72 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 12 73 6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 13 74 6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 13 75 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 13 76 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 14 77 7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 14 78 7.3. Server configuration . . . . . . . . . . . . . . . . . . 14 79 7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 15 80 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 15 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 12.2. Informative References . . . . . . . . . . . . . . . . . 17 87 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 NTP Version 4 (NTPv4) has been widely used since its publication as 93 RFC 5905 [RFC5905]. This documentation is a collection of Best 94 Practices from across the NTP community. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Keeping NTP up to date 104 The best way to protect computers and networks against undefined 105 behavior and security threats related to time is to keep their NTP 106 implementations current. 108 There are always new ideas about security on the Internet, and an 109 application which is secure today could be insecure tomorrow once an 110 unknown bug (or a known behavior) is exploited in the right way. 111 Even our definition of what is secure has evolved over the years, so 112 code which was considered secure when it was written can be 113 considered insecure after some time. 115 Many security mechanisms rely on time as part of their operation. If 116 an attacker can spoof the time, they may be able to bypass or 117 neutralize other security elements. For example, incorrect time can 118 disrupt the ability to reconcile logfile entries on the affected 119 system with events on other systems. 121 Thousands of individual bugs have been found and fixed in the NTP 122 Project's reference implementation since the first NTPv4 release in 123 1997. Each version release contains at least a few bug fixes. The 124 best way to stay in front of these issues is to keep your NTP 125 implementation current. 127 There are multiple versions of the NTP protocol in use, and multiple 128 implementations in use, on many different platforms. It is 129 recommended that NTP users actively monitor wherever they get their 130 software to find out if their versions are vulnerable to any known 131 attacks, and deploy updates containing security fixes as soon as 132 practical. 134 The reference implementation of NTP Version 4 from Network Time 135 Foundation (NTF) continues to be actively maintained and developed by 136 NTF's NTP Project, with help from volunteers and NTF's supporters. 137 The NTP software can be downloaded from ntp.org [1] and also from 138 NTF's github page [2]. 140 3. General Network Security Best Practices 142 3.1. BCP 38 144 Many network attacks rely on modifying the IP source address of a 145 packet to point to a different IP address than the computer which 146 originated it. This modification/abuse vector has been known for 147 quite some time, and BCP 38 [RFC2827] was approved in 2000 to address 148 this. BCP 38 [RFC2827] calls for filtering outgoing and incoming 149 traffic to make sure that the source and destination IP addresses are 150 consistent with the expected flow of traffic on each network 151 interface. It is recommended that all networks (and ISP's of any 152 size) implement this. If a machine on a network is sending out 153 packets claiming to be from an address that is not on that network, 154 this could be the first indication that there is a machine that has 155 been compromised, and is being used abusively. If packets are 156 arriving on an external interface with a source address that should 157 only be seen on an internal network, that's a strong indication that 158 an attacker is trying to inject spoofed packets into the network. 159 More information is available at http://www.bcp38.info . 161 4. NTP Configuration Best Practices 163 These Best Practices, while based on the ntpd reference 164 implementation maintained by the Network Time Foundation, may be 165 applicable to other implementations as well. 167 4.1. Use enough time sources 169 NTP takes the available sources of time and submits their timing data 170 to intersection and clustering algorithms, looking for the best idea 171 of the correct time. If there is only 1 source of time, the answer 172 is obvious. It may not be a good source of time, but it's the only 173 one. If there are 2 sources of time and they agree well enough, 174 that's good. But if they don't, then ntpd has no way to know which 175 source to believe. This gets easier if there are 3 sources of time. 176 But if one of those 3 sources becomes unreachable or unusable, we're 177 back to only having 2 time sources. 4 sources of time is another 178 interesting choice, assuming things go well. If one of these sources 179 develops a problem there are still 3 others. Seems good. But during 180 the leap second we had in June of 2015, several operators implemented 181 leap smearing while others did not, and many NTP end nodes became 182 very confused. See Section 4.6.1 for more information. 184 Starting with ntp-4.2.6, the 'pool' directive will spin up "enough" 185 associations to provide robust time service, and will disconnect poor 186 servers and add in new servers as-needed. 188 Monitor your ntpd instances. If your times sources do not generally 189 agree, find out why and either correct the problems or stop using 190 defective servers. See Section 4.4 for more information. 192 4.2. Use a diversity of Reference Clocks 194 When using servers with attached hardware reference clocks, it is 195 recommended that several different types of reference clocks be used. 196 Having a diversity of sources means that any one issue is less likely 197 to cause a service interruption. 199 Are all clocks on a network from the same vendor? They may have the 200 same bugs. Are they using the same base chipset, regardless of 201 whether or not the finished products are from different vendors? Are 202 they all running the same version of firmware? Chipset and firmware 203 bugs can happen, but is often more difficult to diagnose than a 204 standard software bug. 206 A systemic problem with time from any satellite navigation service is 207 possible and has happened. Sunspot activity can render satellite or 208 radio-based time source unusable. 210 4.3. Mode 6 and 7 212 NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit 213 monitoring and optional authenticated control of ntpd and its 214 configuration. Used properly, these facilities provide vital 215 debugging and performance information and control. Used improperly, 216 these facilities can be an abuse vector. 218 Mode 7 queries have been disabled by default since 4.2.7p230, 219 released on 2011/11/01. Do not enable Mode 7 unless there is a 220 compelling reason to do so. 222 The ability to use Mode 6 beyond its basic monitoring capabilities 223 can be limited to authenticated sessions that provide a 'controlkey', 224 and similarly, if Mode 7 has been explicitly enabled its use for more 225 than basic monitoring can be limited to authenticated sessions that 226 provide a 'requestkey'. 228 Older versions of the reference implementation of NTP could be abused 229 to participate in high-bandwidth DDoS attacks, if the above 230 restrictions are not applied. Starting with ntp-4.2.7p26, released 231 in April of 2010, ntpd requires the use of a nonce before replying 232 with potentially large response packets. 234 As mentioned above, there are two general ways to use Mode 6 and Mode 235 7 requests. One way is to query ntpd for information, and this mode 236 can be disabled with: 238 restrict ... noquery 240 The second way to use Mode 6 and Mode 7 requests is to modify ntpd's 241 behavior. Modification of ntpd ordinarily requires an authenticated 242 session. By default, if no authentication keys have been specified 243 no modifications can be made. For additional protection, the ability 244 to perform these modifications can be controlled with: 246 restrict ... nomodify 248 Users can prevent their NTP servers from participating by adding the 249 following to their ntp.conf file: 251 restrict default -4 nomodify notrap nopeer noquery 253 restrict default -6 nomodify notrap nopeer noquery 255 restrict source nomodify notrap noquery # nopeer is OK if you don't 256 use the 'pool' directive 258 4.4. Monitoring 260 The reference implementation of NTP allows remote monitoring. The 261 access to this service is controlled by the restrict statement in 262 NTP's configuration file (ntp.conf). The syntax reads: 264 restrict address mask address_mask nomodify 266 Monitor ntpd instances so machines that are "out of sync" can be 267 quickly identified. Monitor system logs for messages from ntpd so 268 abuse attempts can be quickly identified. 270 If a system starts getting unexpected time replies from its time 271 servers, that can be an indication that the IP address of the server 272 is being forged in requests to that time server, and these abusers 273 are trying to convince your time servers to stop serving time to the 274 system. 276 If a system is a broadcast client and its syslog shows that it is 277 receiving "early" time messages from its server, that is an 278 indication that somebody may be forging packets from a broadcast 279 server. 281 If a server's syslog shows messages that indicates it is receiving 282 timestamps that are earlier than the current system time, then either 283 the system clock is unusually fast or somebody is trying to launch a 284 replay attack against that server. 286 If a system is using broadcast mode and is running ntp-4.2.8p6 or 287 later, use the 4th field of the ntp.keys file to identify the IPs of 288 machines that are allowed to serve time to the group. 290 4.5. Using Pool Servers 292 It only takes a small amount of bandwidth and system resources to 293 synchronize one NTP client, but NTP servers that can service tens of 294 thousands of clients take more resources to run. Users who want to 295 synchronize their computers should only synchronize to servers that 296 they have permission to use. 298 The NTP pool project is a collection of volunteers who have donated 299 their computing and bandwidth resources to provide time on the 300 Internet for free. The time is generally of good quality, but comes 301 with no guarantee whatsoever. If you are interested in using the 302 pool, please review their instructions at http://www.pool.ntp.org/en/ 303 use.html . 305 If you want to synchronize many computers using the pool, consider 306 running your own NTP servers, synchronizing them to the pool, and 307 synchronizing your clients to your in-house NTP servers. This 308 reduces the load on the pool. 310 If you would like to contribute a server with a static IP address and 311 a permanent Internet conenction to the pool, please consult the 312 instructions at pool.ntp.org [4] . 314 4.6. Leap Second Handling 316 The UTC timescale is kept in sync with the rotation of the earth 317 through the use of leap seconds. NTP time is based on the UTC 318 timescale, and the protocol has the capability to broadcast leap 319 second information. Some GNSS systems (like GPS) broadcast leap 320 second information, so if you have a Stratum-1 server synced to GNSS 321 (or you are synced to a lower stratum server that is ultimately 322 synced to GNSS), you will get advance notification of impending leap 323 seconds automatically. 325 While earlier versions of NTP contained some ambiguity regarding when 326 leap seconds could occur, RFC 5905 is clear that leap seconds are 327 processed at the end of a month. If an upstream server is 328 broadcasting that a leap second is pending, RFC5905-compliant servers 329 should apply it at the end of the last minute of the last day of the 330 month. 332 The IETF maintains a leap second list 333 (https://www.ietf.org/timezones/data/leap-seconds.list) for NTP users 334 who are not receiving leap second information through an automatic 335 source. The use of leap second files requires ntpd 4.2.6 or later. 336 After fetching the leap seconds file onto the server, add this line 337 to ntpd.conf to apply the file: 339 leapfile "/path/to your/leap-file" 341 You will need to restart to apply the changes. 343 Files are also available from other sources: 345 NIST: ftp://time.nist.gov/pub/leap-seconds.list 347 US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap- 348 seconds.list 350 IERS (announces leap seconds): 351 https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 353 Servers with a manually configured leap second file will ignore leap 354 second information broadcast from upstream NTP servers until the leap 355 second file expires. 357 4.6.1. Leap Smearing 359 Some NTP installations may instead make use of a technique called 360 "Leap Smearing". With this method, instead of introducing an extra 361 second (or eliminating a second), NTP time will be slewed in small 362 increments over a comparably large window of time around the leap 363 second event. The amount of the slew should be small enough that 364 clients will follow the smeared time without objecting. During the 365 adjustment window, the NTP server's time may be offset from UTC by as 366 much as .5 seconds. This is done to enable software that doesn't 367 deal with minutes that have more or less than 60 seconds to function 368 correctly, at the expense of fidelity to UTC during the smear window. 370 Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47. 371 Support is not configured by default and must be added at compile 372 time. In addition, no leap smearing will occur unless a leap smear 373 interval is specified in ntpd.conf . For more information, refer to 374 http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno . 376 Leap Smearing must not be used for public-facing NTP servers, as they 377 will disagree with non-smearing servers (as well as UTC) during the 378 leap smear interval. However, be aware that some public-facing 379 servers may be configured this way anyway in spite of this guidance. 381 System Administrators are advised to be aware of impending leap 382 seconds and how the servers (inside and outside their organization) 383 they are using deal with them. Individual clients must never be 384 configured to use a mixture of smeared and non-smeared servers. 386 5. NTP Security Mechanisms 388 In the standard configuration NTP packets are exchanged unprotected 389 between client and server. An adversary that is able to become a 390 Man-In-The-Middle is therefore able to drop, replay or modify the 391 content of the NTP packet, which leads to degradation of the time 392 synchronization or the transmission of false time information. A 393 profound threat analysis for time synchronization protocols are given 394 in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms 395 to protect authenticity and integrity of the NTP packets. Both 396 measures protect the NTP packet by means of a Message Authentication 397 Code (MAC). Neither of them encrypts the NTP's payload, because it 398 is not considered to be confidential. 400 5.1. Pre-Shared Key Approach 402 This approach applies a symmetric key for the calculation of the MAC, 403 which protects authenticity and integrity of the exchanged packets 404 for a association. NTP does not provide a mechanism for the exchange 405 of the keys between the associated nodes. Therefore, for each 406 association, keys have to be exchanged securely by external means. 407 It is recommended that each association is protected by its own 408 unique key. NTP does not provide a mechanism to automatically 409 refresh the applied keys. It is therefore recommended that the 410 participants periodically agree on a fresh key. The calculation of 411 the MAC may always be based on an MD5 hash. If the NTP daemon is 412 built against an OpenSSL library, NTP can also base the calculation 413 of the MAC upon the SHA-1 or any other digest algorithm supported by 414 each side's OpenSSL library. 416 To use this approach the communication partners have to exchange the 417 key, which consists of a keyid with a value between 1 and 65534, 418 inclusive, and a label which indicates the chosen digest algorithm. 419 Each communication partner adds this information to their key file in 420 the form: 422 keyid label key 423 The key file contains the key in clear text. Therefore it should 424 only be readable by the NTP process. Different keys are added line 425 by line to the key file. 427 A NTP client establishes a protected association by appending the 428 option "key keyid" to the server statement in the NTP configuration 429 file: 431 server address key keyid 433 Note that the NTP process has to trust the applied key. An NTP 434 process explicitly has to add each key it want to trust to a list of 435 trusted keys by the "trustedkey" statement in the NTP configuration 436 file. 438 trustedkey keyid_1 keyid_2 ... keyid_n 440 5.2. Autokey 442 Autokey was designed in 2003 to provide a means for clients to 443 authenticate servers. By 2011, security researchers had identified 444 computational areas in the Autokey protocol that, while secure at the 445 time of its original design, were no longer secure. Work was begun 446 on an enhanced replacement for Autokey, which was called Network Time 447 Security (NTS) [6]. NTS was published in the summer of 2013. As of 448 February 2016, this effort was at draft #13, and about to begin 449 'final call'. The first unicast implementation of NTS was started in 450 the summer of 2015 and is expected to be released in the summer of 451 2016. 453 We recommend that Autokey NOT BE USED. Know that as of the fall of 454 2011, a common(?) laptop computer could crack the security cookie 455 used in the Autokey protocol in 30 minutes' time. If you must use 456 Autokey, know that your session keys should be set to expire in under 457 30 minutes' time. 459 6. NTP Security Best Practices 461 6.1. Minimizing Information Leakage 463 The base NTP packet leaks important information (including reference 464 ID and reference time) that can be used in attacks [NDSS16], 465 [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this 466 information by sending mode 3 queries to a target system and 467 inspecting the fields in the mode 4 response packet. NTP control 468 queries also leak important information (including reference ID, 469 expected origin timestamp, etc) that can be used in attacks 470 [CVE-2015-8139]. A remote attacker can learn this information by 471 sending control queries to a target system and inspecting the 472 response. 474 As such, access control should be used to limit the exposure of this 475 information to third parties. 477 All hosts should only respond to NTP control queries from authorized 478 parties. One way to do this is to only allow control queries from 479 authorized IP addresses. 481 A host that is not supposed to act as an NTP server that provides 482 timing information to other hosts should additionally drop incoming 483 mode 3 timing queries. 485 An "end host" is host that is using NTP solely for the purpose of 486 adjusting its own system time. Such a host is not expected to 487 provide time to other hosts, and relies exclusively on NTP's basic 488 mode to take time from a set of servers. (That is, the host sends 489 mode 3 queries to its servers and receives mode 4 responses from 490 these servers containing timing information.) To minimize 491 information leakage, end hosts should drop all incoming NTP packets 492 except mode 4 response packets that come from its configured servers. 494 6.2. Avoiding Daemon Restart Attacks 496 [RFC5905] says NTP clients should not accept time shifts greater than 497 the panic threshold. Specifically, RFC5905 says "PANIC means the 498 offset is greater than the panic threshold PANICT (1000 s) and SHOULD 499 cause the program to exit with a diagnostic message to the system 500 log. 502 However, this behavior can be exploited by attackers [NDSS16], when 503 the following two conditions hold: 505 1. The operating system automatically restarts the NTP daemon when 506 it quits. (Modern *NIX operating systems are replacing 507 traditional init systems with process supervisors, such as 508 systemd, which can be configured to automatically restart any 509 daemons that quit. This behavior is the default in CoreOS and 510 Arch Linux. It is likely to become the default behavior in other 511 systems as they migrate legacy init scripts to systemd.) 513 2. The NTP daemon ignores the panic threshold when it is restarted. 514 (This is sometimes called the -g option.) 516 In such cases, the attacker can send the target an offset that 517 exceeds the panic threshold, causing the client to quit. Then, when 518 the client restarts, it ignores the panic threshold and accepts the 519 attacker's large offset. 521 Hosts running with the above two conditions should be aware that the 522 panic threshold does not protect them from attacks. A natural 523 solution is not to run hosts with these conditions. 525 As an alternative, the following steps could be taken to mitigate the 526 risk of attack. 528 o Monitor NTP system log to detect when the NTP daemon has quit due 529 to a panic event, as this could be a sign of an attack. 531 o Request manual intervention when a timestep larger than the panic 532 threshold is detected. 534 o Prevent the NTP daemon from taking time steps that set the clock 535 to a time earlier than the compile date of the NTP daemon. 537 o Modify the NTP daemon so that it "hangs" (ie does not quit, but 538 just waits for a better timing samples but does not modify the 539 local clock) when it receives a large offset. 541 6.3. Detection of Attacks Through Monitoring 543 Users should monitor their NTP instances to detect attacks. Many 544 known attacks on NTP have particular signatures. Common attack 545 signatures include: 547 1. "Bogus packets" - A packet whose origin timestamp does not match 548 the value that expected by the client. 550 2. "Zero origin packet" - A packet with a origin timestamp set to 551 zero [CVE-2015-8138]. 553 3. A packet with an invalid cryptographic MAC [CCR16]. 555 The observation of many such packets could indicate that the client 556 is under attack. 558 Also, Kiss-o'-Death (KoD) packets can be used in denial of service 559 attacks. Thus, the observation of even just one KoD packet with a 560 high poll value (e.g. poll>10) could be sign that the client is under 561 attack. 563 6.4. Broadcast Mode Should Only Be Used On Trusted Networks 565 Per [RFC5905], NTP's broadcast mode is authenticated using symmetric 566 key cryptography. The broadcast server and all of its broadcast 567 clients share a symmetric cryptographic key, and the broadcast server 568 uses this key to append a message authentication code (MAC) to the 569 broadcast packets it sends. 571 Importantly, all broadcast clients that listen to this server must 572 know the cryptographic key. This mean that any client can use this 573 key to send valid broadcast messages that look like they come from 574 the broadcast server. Thus, a rogue broadcast client can use its 575 knowledge of this key to attack the other broadcast clients. 577 For this reason, an NTP broadcast server and all its client must 578 trust each other. Broadcast mode should only be run from within a 579 trusted network. 581 6.5. Symmetric Mode Should Only Be Used With Trusted Peers 583 In symmetric mode, two peers Alice and Bob can both push and pull 584 synchronization to and from each other using either ephemeral 585 symmetric passive (mode 2) or persistent symmetric active (NTP mode 586 1) packets. The persistent association is preconfigured and 587 initiated at the active peer but not preconfigured at the passive 588 peer (Bob). Upon arrival of a mode 1 NTP packet from Alice, Bob 589 mobilizes a new ephemeral association if he does not have one 590 already. This is a security risk for Bob because an arbitrary 591 attacker can attempt to change Bob's time by asking Bob to become its 592 symmetric passive peer. 594 For this reason, a host (Bob) should only allow symmetric passive 595 associations to be established with trusted peers. Specifically, Bob 596 should require each of its symmetric passive association to be 597 cryptographically authenticated. Each symmetric passive association 598 should be authenticated under a different cryptographic key. 600 The use of a different cryptographic key per peer prevents a Sybil 601 attack, where a single malicious peer uses the same cryptographic key 602 to set up multiple symmetric associations a target, and thus bias the 603 results of the target's Byzantine fault tolerant peer selection 604 algorithms. 606 7. NTP in Embedded Devices 608 Readers of this BCP already understand how important accurate time is 609 for network computing. And as computing becomes more ubiquitous, 610 there will be many small "Internet of Things" devices that require 611 accurate time. These embedded devices may not have a traditional 612 user interface, but if they connect to the Internet they will be 613 subject to the same security threats as traditional deployments. 615 7.1. Updating Embedded Devices 617 Vendors of embedded devices have a special responsibility to pay 618 attention to the current state of NTP bugs and security issues, 619 because their customers usually don't have the ability to update 620 their NTP implementation on their own. Those devices may have a 621 single firmware upgrade, provided by the manufacturer, that updates 622 all capabilities at once. This means that the vendor assumes the 623 responsibility of making sure their devices have the latest NTP 624 updates applied. 626 This should also include the ability to update the NTP server 627 address. 629 There is a catalog of NTP server abuse incidents, some of which 630 involve embedded devices, on the Wikipedia page for NTP Server Misuse 631 and Abuse [7]. 633 7.2. KISS Packets 635 The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a 636 server can tell a misbehaving client to "back off" its query rate. 637 It is important for all NTP devices to respect these packets and back 638 off when asked to do so by a server. It is even more important for 639 an embedded device, which may not have exposed a control interface 640 for NTP. 642 The KoD mechanism relies on clients behaving properly in order to be 643 effective. Some clients ignore the KoD packet entirely, and other 644 poorly-implemented clients might unintentionally increase their poll 645 rate and simulate a denial of service attack. Server administrators 646 should be prepared for this and take measures outside of the NTP 647 protocol to drop packets from misbehaving clients. 649 7.3. Server configuration 651 Vendors of embedded devices that need time synchronization should 652 also carefully consider where they get their time from. There are 653 several public-facing NTP servers available, but they may not be 654 prepared to service requests from thousands of new devices on the 655 Internet. 657 Vendors are encouraged to invest resources into providing their own 658 time servers for their devices to connect to. 660 7.3.1. Get a vendor subdomain for pool.ntp.org 662 The NTP Pool Project offers a program where vendors can obtain their 663 own subdomain that is part of the NTP Pool. This offers vendors the 664 ability to safely make use of the time distributed by the Pool for 665 their devices. Vendors are encouraged to support the pool if they 666 participate. For more information, visit http://www.pool.ntp.org/en/ 667 vendors.html . 669 8. NTP over Anycast 671 Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 672 [RFC7094]). With anycast, a single IP address is assigned to 673 multiple interfaces, and routers direct packets to the closest active 674 interface. 676 Anycast is often used for Internet services at known IP addresses, 677 such as DNS. Anycast can also be used in large organizations to 678 simplify configuration of a large number of NTP clients. Each client 679 can be configured with the same NTP server IP address, and a pool of 680 anycast servers can be deployed to service those requests. New 681 servers can be added to or taken from the pool, and other than a 682 temporary loss of service while a server is taken down, these 683 additions can be transparent to the clients. 685 If clients are connected to an NTP server via anycast, the client 686 does not know which particular server they are connected to. As 687 anycast servers may arbitrarily enter and leave the network, the 688 server a particular client is connected to may change. This may 689 cause a small shift in time from the perspective of the client when 690 the server it is connected to changes. It is recommended that 691 anycast be deployed in environments where these small shifts can be 692 tolerated. 694 Configuration of an anycast interface is independent of NTP. Clients 695 will always connect to the closest server, even if that server is 696 having NTP issues. It is recommended that anycast NTP 697 implementations have an independent method of monitoring the 698 performance of NTP on a server. If the server is not performing to 699 specification, it should remove itself from the Anycast network. It 700 is also recommended that each Anycast NTP server have at least one 701 Unicast interface, so its performance can be checked independently of 702 the anycast routing scheme. 704 One useful application in large networks is to use a hybrid unicast/ 705 anycast approach. Stratum 1 NTP servers can be deployed with unicast 706 interfaces at several sites. Each site may have several Stratum 2 707 servers with two ethernet interfaces. One interface has a unique 708 unicast IP address. The second has an anycast IP interface (with a 709 shared IP address per location). The unicast interfaces can be used 710 to obtain time from the Stratum 1 servers globally (and perhaps peer 711 with the other Stratum 2 servers at their site). Clients at each 712 site can be configured to use the shared anycast address for their 713 site, simplifying their configuration. Keeping the anycast routing 714 restricted on a per-site basis will minimize the disruption at the 715 client if its closest anycast server changes. Each Stratum 2 server 716 can be uniquely identified on their unicast interface, to make 717 monitoring easier. 719 9. Acknowledgements 721 The authors wish to acknowledge the contributions of Sue Graves, 722 Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon 723 Goldberg, and Martin Burnicki. 725 10. IANA Considerations 727 This memo includes no request to IANA. 729 11. Security Considerations 731 Time is a fundamental component of security on the internet. 732 Credentials and certificates can expire. Logins and other forms of 733 access can be revoked after a period of time, or at a scheduled time. 734 And some applications may assume that system time cannot be changed 735 and is always monotonic, and vulnerabilites may be exposed if a time 736 in the past is forced into a system. Therefore, any system 737 adminstrator concerned with security should be concerned with how the 738 current time gets into their system. 740 [NTS] is an Internet-Draft of a collection of methods to secure time 741 transfer over networks. [NTSFORNTP] is an Internet-Draft that 742 applies the methods in [NTS] specifically to NTP. At the time of 743 this writing, these are still drafts. Readers are encourages to 744 check the status of these drafts, and make use of the methods they 745 describe. 747 12. References 749 12.1. Normative References 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, 753 DOI 10.17487/RFC2119, March 1997, 754 . 756 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 757 Defeating Denial of Service Attacks which employ IP Source 758 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 759 May 2000, . 761 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 762 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 763 December 2006, . 765 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 766 "Network Time Protocol Version 4: Protocol and Algorithms 767 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 768 . 770 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 771 "Architectural Considerations of IP Anycast", RFC 7094, 772 DOI 10.17487/RFC7094, January 2014, 773 . 775 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 776 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 777 October 2014, . 779 12.2. Informative References 781 [CCR16] Malhotra, and Goldberg, "Attacking NTP's Authenticated 782 Broadcast Mode", 2016. 784 [CVE-2015-8138] 785 Van Gundy, and Gardner, "NETWORK TIME PROTOCOL ORIGIN 786 TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, 787 . 789 [CVE-2015-8139] 790 Van Gundy, , "NETWORK TIME PROTOCOL NTPQ AND NTPDC ORIGIN 791 TIMESTAMP DISCLOSURE VULNERABILITY", 2016, 792 . 794 [CVE-2016-1548] 795 Gardner, and Lichvar, "Xleave Pivot: NTP Basic Mode to 796 Interleaved", 2016, . 799 [NDSS16] Malhotra, , Cohen, , Brakke, , and Goldberg, "Attacking 800 the Network Time Protocol", 2016, 801 . 803 [NTS] "Network Time Security", 804 . 807 [NTSFORNTP] 808 "Using the Network Time Security Specification to Secure 809 the Network Time Protocol", 810 . 813 12.3. URIs 815 [1] http://www.ntp.org/downloads.html 817 [2] https://github.com/ntp-project/ntp 819 [4] http://www.pool.ntp.org/en/join.html 821 [6] https://tools.ietf.org/html/draft-ietf-ntp-network-time- 822 security-00 824 [7] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse 826 Authors' Addresses 828 Denis Reilly 829 Spectracom Corporation 830 1565 Jefferson Road, Suite 460 831 Rochester, NY 14623 832 US 834 Email: denis.reilly@spectracom.orolia.com 836 Harlan Stenn 837 Network Time Foundation 838 P.O. Box 918 839 Talent, OR 97540 840 US 842 Email: stenn@nwtime.org 843 Dieter Sibold 844 Physikalisch-Technische Bundesanstalt 845 Bundesallee 100 846 Braunschweig D-38116 847 Germany 849 Phone: +49-(0)531-592-8420 850 Fax: +49-531-592-698420 851 Email: dieter.sibold@ptb.de