idnits 2.17.1 draft-ietf-ntp-refid-updates-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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2017) is 2340 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC0791' is mentioned on line 328, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Stenn 3 Internet-Draft Network Time Foundation 4 Intended status: Standards Track S. Goldberg 5 Expires: June 2, 2018 Boston University 6 November 29, 2017 8 Network Time Protocol REFID Updates 9 draft-ietf-ntp-refid-updates-01 11 Abstract 13 RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines 14 the value of the REFID, the system peer for the responding host. In 15 the past, for IPv4 associations the IPv4 address is used, and for 16 IPv6 associations the first four octets of the MD5 hash of the IPv6 17 are used. There are at least three shortcomings to this approach, 18 and this proposal will address the three so noted. One is that 19 knowledge of the system peer is "abusable" information and should not 20 be generally available. The second is that the four octet hash of 21 the IPv6 address looks very much like an IPv4 address, and this is 22 confusing. The third is that a growing number of low-stratum servers 23 want to offer leap-smeared time to their clients, and there is no 24 obvious way to know if a server is offering accurate time or leap- 25 smeared time. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 2, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. The REFID . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.2. NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. IPv6 REFID . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.4. Leap-Smear REFID . . . . . . . . . . . . . . . . . . . . 4 66 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. The NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 6 70 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6 72 3.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. The REFID sent to clients during a Leap-Smear . . . . . . . . 7 74 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Leap Smear REFID . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 1.1. The REFID 89 The interpretation of a REFID is based on the stratum, as documented 90 in RFC 5905 [RFC5905], section 7.3, "Packet Header Variables". The 91 core reason for the REFID in the NTP Protocol is to prevent a degree- 92 one timing loop, where server B decides to follow A as its time 93 source, and A then decides to follow B as its time source. 95 At Stratum 2+, which will be the case if two servers A and B are 96 exchanging timing information, then if server B follows A as its time 97 source, A's address will be B's REFID. When A uses IPv4, the default 98 REFID is A's IPv4 address. When A uses IPv6, the default REFID is a 99 four-octet digest of A's IPv6 address. Now, if A queries B for its 100 time, then A will learn that B is using A as its time source by 101 observing A's address in the REFID field of the response packet sent 102 by B. Thus, A will not select B as a potential time source, since 103 this would cause a timing loop. 105 1.2. NOT-YOU REFID 107 This REFID mechanism, however, also allows a third-party C to learn 108 that A is the time source that is being used by B. When A is using 109 IPv4, C can learn this by querying B for its time, and observing that 110 the REFID in B's response is the IPv4 address of A. Meanwhile, when 111 A is using IPv6, then C can again query B for its time, and then can 112 use an offline dictionary attack to attempt to determine the IPv6 113 address that corresponds to the digest value in the response sent by 114 B. C could construct the necessary dictionary by compiling a list of 115 publically accessible IPv6 servers. Remote attackers can use this 116 technique to attempt to identify the time sources used by a target, 117 and then send spoofed packets to the target or its time source in an 118 attempt to disrupt time service, as was done e.g., in [NDSS16] or 119 [CVE-2015-8138]. 121 The REFID thus unnecessarily leaks information about a target's time 122 server to remote attackers. The best way to mitigate this 123 vulnerability is to decouple the IP address of the time source from 124 the REFID. To do this, a system can use an otherwise-impossible 125 value for its REFID, called the "not-you" value, when it believes 126 that a querying system is not its time source. 128 The NOT-YOU REFID proposal is backwards-compatible. It can be 129 implemented by one peer in an NTP association without any changes to 130 the other peer. 132 The NOT-YOU REFID proposal does have a small risk, in that a system 133 that might return NOT-YOU does not have perfect information, and it 134 is possible that the remote system peer is contacting "us" via a 135 different network interface. In this case, the remote system might 136 choose us as their system peer, and a degree-one timing loop will 137 occur. In this case, however, the two systems will spiral into worse 138 stratum positions with increasing root distances, and eventually the 139 loop will break. If any other systems are available as time servers, 140 one of them will become the new system peer. However, until this 141 happens the two spiraling systems will have degraded time quality. 143 1.3. IPv6 REFID 145 In a trusted situation, an operator might well choose to expose the 146 real REFID. RFC 5905 [RFC5905], section 7.3, "Packet Header 147 Variables", explains how a remote system peer is converted to a 148 REFID. It says: 150 If using the IPv4 address family, the identifier is the four-octet 151 IPv4 address. If using the IPv6 family, it is the first four 152 octets of the MD5 hash of the IPv6 address. ... 154 However, the MD5 hash of an IPv6 address often looks like a valid 155 IPv4 address. When this happens, an operator cannot tell if the 156 REFID refers to an IPv6 address or and IPv4. Specifically, the NTP 157 Project has received a report where the generated IPv6 hash decoded 158 to the IPv4 address of a different machine on the system peer's 159 network. 161 This proposal offers a way for a system to generate a REFID for a 162 IPv6 system peer that does not conflict with an IPv4-based REFID. 164 This proposal is not fully backwards-compatible. It SHOULD be 165 implemented by both peers in an NTP association. Having said this, 166 however, in a properly-designed NTP network there is negligible risk 167 of a degree-one timing loop if only one system implements and uses 168 the IPv6 REFID. This backward incompatability can be avoided by 169 using the proposed I-DO protocol. 171 1.4. Leap-Smear REFID 173 RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming 174 method of distributing time on networks. Leap Seconds will continue 175 to exist for a good number of years' time, and since the timescale 176 mandated by POSIX effectively ignores any instances where there are 177 not 86,400 seconds' time in a day something must be done to reliably 178 synchronize clocks during the application of leap second corrections. 179 One mechanism for dealing with the application that has recently 180 become visible is to apply the leap second using a "smear", where the 181 time reported by leap-second aware servers is gradually adjusted so 182 there is no major disruption to time synchronization when processing 183 a leap second. 185 While the proper handling of leap seconds can be expected from up-to- 186 date software and time servers, there are large numbers of out-of- 187 date software installations and systems that are just not able to 188 properly handle a leap second correction. 190 This proposal offers a way for a system to generate a REFID that 191 indicates that the time being supplied in the NTP packet already 192 contains an amount of leap smear correction, and what that amount is. 194 This proposal is backwards-compatible in all but poorly-designed NTP 195 networks. The entire point of providing NTP servers that offer leap- 196 smeared time in response to CLIENT requests is to provide smooth time 197 to clients that are unable to properly handle leap seconds. If an 198 operator is skilled enough to provide leap-smeared time to a subset 199 of clients that cannot properly handle leap seconds, they can be 200 expected to know enough to avoid using leap-smeared time between time 201 servers that are expected to be able to properly handle leap seconds. 202 Leap smears are expected to be implemented on a limited number of 203 time servers where there is a base of client systems that cannot 204 handle a leap second correction. Furthermore, even in a poorly- 205 designed NTP network the "window of risk" lasts only as long as it 206 takes for the leap second to be smeared. 208 1.5. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 2. The NOT-YOU REFID 216 2.1. Proposal 218 When enabled, this proposal allows the one-degree loop detection to 219 work and useful diagnostic information to be provided to trusted 220 partners while keeping potentially abusable information from being 221 disclosed to ostensibly uninterested parties. It does this by 222 returning the normal REFID to queries that come from trusted 223 addresses or from an address that the current system believes is its 224 time source (aka its "system peer"), and otherwise returning a 225 special IP address that is interpreted to mean "not you". The "not 226 you" IP address is 127.127.127.127 when the query is made from an 227 IPv4 address, or when the query is made from an IPv6 address whose 228 four-octect hash does not equal 127.127.127.127. The "not you" IP 229 address is 127.127.127.128 when the query is made from an address 230 whose four-octect hash equals 127.127.127.127. 232 Note that this mechanism fully supports degree-one loop detection in 233 the case where the responding NOT-YOU system can accurately detect 234 when it's getting a request from its system peer, and otherwise 235 provides the most basic diagnostic information to third parties. 237 This proposal will hide the current system's system peer from 238 querying systems that the current system believes are not the current 239 system's system peer. Note well, however, that the current system 240 will return the "not you" value to a query from its system peer if 241 the system peer sends its query from an unexpected IP address. Put 242 another way, the responding system has imperfect knowledge about 243 whether or not the sender is its system peer and there are cases 244 where it will offer a NOT-YOU response to its system peer, which will 245 then produce a degree-one timing loop. 247 3. Augmenting the IPv6 REFID Hash 249 3.1. Background 251 In a trusted network, the S2+ REFID is generated based on the network 252 system peer. RFC 5905 [RFC5905] says: 254 If using the IPv4 address family, the identifier is the four-octet 255 IPv4 address. If using the IPv6 family, it is the first four 256 octets of the MD5 hash of the IPv6 address. ... 258 This means that the IPv4 representation of the IPv6 hash would be: 259 b1.b2.b3.b4 . The proposal is that the system MAY also use 260 255.b2.b3.b4 as its REFID. This reduces the risk of ambiguity, since 261 addresses beginning with 255 are "reserved", and thus will not 262 collide with valid IPv4 on the network. 264 When using the REFID to check for a timing loop for an IPv6 265 association, if the code that checks the first four-octets of the 266 hash fails to match then the code must check again, using 0xFF as the 267 first octet of the hash. 269 3.2. Potential Problems 271 There is a 1 in 16,777,216 chance that the REFID hashes of two IPv6 272 addresses will be identical, producing a false-positive loop 273 detection. With a sufficient number of servers, the risk of this 274 problem becomes a non-issue. The use of the NOT-YOU REFID and/or the 275 proposed "REFID Suggestion" or "I-DO" extension fields are ways to 276 mitigate this potential situation. 278 Unrealistically, if only two instances of NTP are communicating via 279 IPv6 and one side implements this new IPv4 REFID hash and the other 280 side does not, the "other side" will not be able to detect this loop 281 condition. In this case, the two machines will slowly increase their 282 Stratum until they reach S16 and become unsynchronized. This 283 situation is considered to be unrealistic because the only current 284 way this could happen would be for there to only be these two 285 instances of NTP available as time sources in a misconfigured "orphan 286 mode" setup. There is no risk of this happening in an NTP network 287 with 3 or more time sources, or in a properly-configured "time 288 island" setup. 290 3.3. Questions 292 Should we ask IANA to allocate a pseudo Extension Field Type of 293 0xFFFF (for example) so the proposed "I-Do" exchange can report 294 whether or not the "IPv6 REFID Hash" is supported? 296 4. The REFID sent to clients during a Leap-Smear 298 4.1. Background 300 RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming 301 method of distributing time on networks. Leap Seconds will continue 302 to exist for a good number of years' time, and since the timescale 303 mandated by POSIX effectively ignores any instances where there are 304 not 86,400 seconds' time in a day, something must be done to reliably 305 synchronize clocks during the application of leap second corrections. 306 One mechanism for dealing with the application that has recently 307 become visible is to apply the leap second using a "smear", where the 308 time reported by leap-second aware servers is gradually adjusted so 309 there is no major disruption to time synchronization when processing 310 a leap second. 312 While the proper handling of leap seconds can be expected from up-to- 313 date software and time servers, there are large numbers of out-of- 314 date software installations and systems that are just not able to 315 properly handle a leap second correction. 317 This proposal offers a way for a system to generate a REFID that 318 indicates that the time being supplied in the NTP packet already 319 contains an amount of leap smear correction, and what that amount is. 321 4.2. Leap Smear REFID 323 RFC 5905 [RFC5905] defines the data type of NTP time values in 324 Section 6, "Data Types": 326 All NTP time values are represented in twos-complement format, 327 with bits numbered in big-endian (as described in Appendix A of 328 [RFC0791]) fashion from zero starting at the left, or high-order, 329 position. ... 331 The 32 bit signed integer seconds portion and the 32 bit unsigned 332 fractional seconds portion, or 32:32 format is: 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Seconds | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Fraction | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 NTP Timestamp Format (32:32) 344 This format provides coverage for 136 years' time to a precision of 345 232 picoseconds. If a leap-second addition is being completely 346 smeared just before before the stroke of the next POSIX second then 347 the smear correction will be (0,1). If this was the only way to 348 apply a leap smear correction then we could simply use an unsigned 349 value to represent the correction. But while the first popular leap 350 smear implementation applied the correction over an appropriate 351 number of hours' time before the actual leap second so the system 352 time was corrected at the stroke of 00:00, that meant that the 353 difference between system time and UTC spent half of the duration of 354 the smear application at [.5,1) "off" of correct time. The second 355 popular implementation of the leap smear applied the first half- 356 second correction before the stroke of 00:00 for a correction range 357 of (0,.5] and the last half-second correction starting at the stroke 358 of 00:00 for a [-.5,0) correction range. This also means we need a 359 signed value to represent the amount of correction. 361 The REFID of a system that is supplying smeared time to client 362 requests while leap-smear correction is active would be 254.b1.b2.b3, 363 where the three octets (b1, b2, and b3) are a 2:22 formatted value, 364 yielding precision to 238 nanoseconds, or about a quarter of a 365 microsecond. 367 Note that if an NTP server decides to offer smeared time corrections 368 to clients, it SHOULD only offer this time in response to CLIENT time 369 requests. An NTP server that is offering smeared time SHOULD NOT 370 send smeared time in any peer exchanges. Also, CLIENT machines 371 SHOULD NOT be distributing time (smeared or otherwise) to other 372 systems. 374 We also note that during the application of a leap smear, the REFID 375 from a system offering smeared time cannot provide detection of a 376 timing loop. This is not expected to be a problem because time 377 server systems are not expected to make CLIENT connections with each 378 other, so they should not be receiving smeared time. Moreso, if a 379 time server is configured to make CLIENT connections to a server that 380 offers smeared time, with the mechanism described here it can detect 381 when it is getting smeared time, and either ignore time from that 382 source, or "undo" the leap smear correction and use the corrected 383 time for that sample. 385 This proposal is not an attempt to justify servers offering leap 386 smeared time. It is only an attempt to make it easy and visible to 387 identify when a server is offering or client is receiving smeared 388 time, and provide the client a means to know the amount of smear 389 correction as of the latest successful poll. 391 4.3. Questions 393 Should we ask IANA to allocate a pseudo Extension Field Type of 394 0xFFFE (for example) so the proposed "I-Do" exchange can report 395 whether or not this server will offer leap smeared time in response 396 to CLIENT time requests, identifying the amount of correction using 397 the above REFID? 399 5. Acknowledgements 401 For the "not-you" REFID, we acknowledge useful discussions with 402 Aanchal Malhotra and Matthew Van Gundy. 404 For the IPv6 REFID, we acknowledge Dan Mahoney (and perhaps others) 405 for suggesting the idea of using an "impossible" first-octet value to 406 indicate an IPv6 refid hash. 408 For the Leap Smear REFID, we acknowledge useful discussions with 409 Juergen Perlinger. 411 6. IANA Considerations 413 This memo makes no requests of IANA. 415 7. Security Considerations 417 Many systems running NTP are configured to return responses to timing 418 queries by default. These responses contain a REFID field, which 419 generally reveals the address of the system's time source if that 420 source is an IPv4 address. This behavior can be exploited by remote 421 attackers who wish to first learn the address of a target's time 422 source, and then attack the target and/or its time source. As such, 423 the "not-you" REFID proposal is designed to harden NTP against these 424 attacks by limiting the amount of information leaked in the REFID 425 field. 427 Systems running NTP should reveal the identity of their system in 428 peer in their REFID only when they are on a trusted network. The 429 IPv6 REFID proposal provides one way to do this, when the system peer 430 uses addresses in the IPv6 family. 432 8. References 434 8.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 442 "Network Time Protocol Version 4: Protocol and Algorithms 443 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 444 . 446 8.2. Informative References 448 [CVE-2015-8138] 449 Van Gundy, M. and J. Gardner, "Network Time Protocol 450 Origin Timestamp Check Impersonation Vulnerability (CVE- 451 2015-8138)", in TALOS VULNERABILITY REPORT (TALOS- 452 2016-0077), 2016. 454 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 455 "Attacking the Network Time Protocol", in ISOC Network and 456 Distributed System Security Symposium 2016 (NDSS'16), 457 2016. 459 Authors' Addresses 461 Harlan Stenn 462 Network Time Foundation 463 P.O. Box 918 464 Talent, OR 97540 465 US 467 Email: stenn@nwtime.org 469 Sharon Goldberg 470 Boston University 471 111 Cummington St 472 Boston, MA 02215 473 US 475 Email: goldbe@cs.bu.edu