idnits 2.17.1 draft-ietf-ntp-refid-updates-03.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 (June 6, 2018) is 2150 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 317, 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: December 8, 2018 Boston University 6 June 6, 2018 8 Network Time Protocol REFID Updates 9 draft-ietf-ntp-refid-updates-03 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 December 8, 2018. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 publicly 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 REFID value, when it believes 126 that a querying system is not its time source. 128 The NOT-YOU REFID proposal is backwards-compatible and provides the 129 most basic diagnostic information to third parties. It can be 130 implemented by one peer in an NTP association without any changes to 131 the other peer. This holds as long as responding NOT-YOU system can 132 accurately detect when it's getting a request from its system peer. 134 The NOT-YOU REFID proposal does have a small risk. Consider system A 135 that returns the NOT-YOU REFID and system B that has two network 136 interfaces B1 and B2. Suppose that system A is using system B as his 137 time source, via network interface B1. Now suppose that system B 138 queries system A for time via network interface B2. In this case, 139 system A returns the NOT-YOU REFID value to system B, since system A 140 does not realize that network interface B1 and B2 belong to the same 141 system. In this case, system B might choose system A as its time 142 source, and a degree-one timing loop will occur. In this case, 143 however, the two systems will spiral into worse stratum positions 144 with increasing root distances, and eventually the loop will break. 146 If any other systems are available as time servers, one of them will 147 become the new system peer. However, until this happens the two 148 spiraling systems will have degraded time quality. 150 1.3. IPv6 REFID 152 In an environment where all time queries made to a server can be 153 trusted, an operator might well choose to expose the real REFID. RFC 154 5905 [RFC5905], section 7.3, "Packet Header Variables", explains how 155 a remote system peer is converted to a REFID. It says: 157 If using the IPv4 address family, the identifier is the four-octet 158 IPv4 address. If using the IPv6 family, it is the first four 159 octets of the MD5 hash of the IPv6 address. ... 161 However, the MD5 hash of an IPv6 address often looks like a valid 162 IPv4 address. When this happens, an operator cannot tell if the 163 REFID refers to an IPv6 address or and IPv4. Specifically, the NTP 164 Project has received a report where the generated IPv6 hash decoded 165 to the IPv4 address of a different machine on the system peer's 166 network. 168 This proposal offers a way for a system to generate a REFID for a 169 IPv6 system peer that does not conflict with an IPv4-based REFID. 171 This proposal is not backwards-compatible. It SHOULD be implemented 172 by both peers in an NTP association. In the scenario where A and B 173 are peering using IPv6, where A is the system peer and does not 174 understand IPv6 REFID, and B is subordinate and is using IPv6 REFID, 175 A will not be able to determine that B is using A as its system peer 176 and a degree-one timing loop can form. 178 If both peers implement the IPv6 REFID this situation cannot happen. 180 [If at least one of the peers implements the proposed I-DO protocol 181 this situation cannot happen.] 183 1.4. Leap-Smear REFID 185 RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming 186 method of distributing time on networks. Leap Seconds will continue 187 to exist for a good number of years' time, and since the timescale 188 mandated by POSIX effectively ignores any instances where there are 189 not 86,400 seconds' time in a day something must be done to reliably 190 synchronize clocks during the application of leap second corrections. 191 One way to deal with the insertion of a leap second is to apply the 192 leap second using a "smear", where the time reported by leap-second 193 aware servers is gradually adjusted so there is no major disruption 194 to time synchronization when processing a leap second. 196 While the proper handling of leap seconds can be expected from up-to- 197 date software and time servers, there are large numbers of out-of- 198 date software installations and systems that are just not able to 199 properly handle a leap second correction. 201 This proposal offers a way for a system to generate a REFID that 202 indicates that the time being supplied in the NTP packet already 203 contains an amount of leap smear correction, and what that amount is. 205 This proposal is backwards-compatible in all but poorly-designed NTP 206 networks. The entire point of providing NTP servers that offer leap- 207 smeared time in response to CLIENT requests is to provide smooth time 208 to clients that are unable to properly handle leap seconds. If an 209 operator is skilled enough to provide leap-smeared time to a subset 210 of clients that cannot properly handle leap seconds, they can be 211 expected to know enough to avoid using leap-smeared time between time 212 servers that are expected to be able to properly handle leap seconds. 213 Leap smears are expected to be implemented on a limited number of 214 time servers where there is a base of client systems that cannot 215 handle a leap second correction. Furthermore, even in a poorly- 216 designed NTP network the "window of risk" lasts only as long as it 217 takes for the leap second to be smeared. 219 1.5. Requirements Language 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in RFC 2119 [RFC2119]. 225 2. The NOT-YOU REFID 227 2.1. Proposal 229 When enabled, this proposal allows the one-degree loop detection to 230 work and useful diagnostic information to be provided to trusted 231 partners while keeping potentially abusable information from being 232 disclosed to ostensibly uninterested parties. It does this by 233 returning the normal REFID to queries that come from trusted 234 addresses or from an address that the current system believes is its 235 time source (aka its "system peer"), and otherwise returning a 236 special IP address that is interpreted to mean "not you". The "not 237 you" IP address is 127.127.127.127 when the query is made from an 238 IPv4 address, or when the query is made from an IPv6 address whose 239 four-octet hash does not equal 127.127.127.127. The "not you" IP 240 address is 127.127.127.128 when the query is made from an address 241 whose four-octet hash equals 127.127.127.127. 243 This mechanism is correct and transparent when the system responding 244 with a NOT-YOU can accurately detect when it's getting a timing query 245 from its system peer. A querying system that uses IPv4 continues to 246 check that its IPv4 address does not appear in the REFID before 247 deciding whether to take time from the current system. A querying 248 system that uses IPv6 continues to check that the four-octet hash of 249 its IPv6 address does not appear in the REFID before deciding whether 250 to take time from the current system. 252 3. Augmenting the IPv6 REFID Hash 254 3.1. Background 256 In a trusted network, the S2+ REFID is generated based on the network 257 system peer. RFC 5905 [RFC5905] says: 259 If using the IPv4 address family, the identifier is the four-octet 260 IPv4 address. If using the IPv6 family, it is the first four 261 octets of the MD5 hash of the IPv6 address. 263 This means that the IPv4 representation of the IPv6 hash would be: 264 b1.b2.b3.b4 . The proposal is that the system MAY also use 265 255.b2.b3.b4 as its REFID. This reduces the risk of ambiguity, since 266 addresses beginning with 255 are "reserved", and thus will not 267 collide with valid IPv4 on the network. 269 When using the REFID to check for a timing loop for an IPv6 270 association, if the code that checks the first four-octets of the 271 hash fails to match then the code must check again, using 0xFF as the 272 first octet of the hash. 274 3.2. Potential Problems 276 There is a 1 in 16,777,216 chance that the REFID hashes of two IPv6 277 addresses will be identical, producing a false-positive loop 278 detection. With a sufficient number of servers, the risk of this 279 problem becomes a non-issue. [The use of the NOT-YOU REFID and/or 280 the proposed "REFID Suggestion" or "I-DO" extension fields are ways 281 to mitigate this potential situation.] 283 Unrealistically, if only two instances of NTP are communicating via 284 IPv6 and system A implements this new IPv6 REFID hash and system B 285 does not, system B will not be able to detect this loop condition. 286 In this case, the two machines will slowly increase their stratum 287 until they become unsynchronized. This situation is considered to be 288 unrealistic because, for this to happen, each system would have to 289 have only the other system available as a time source, for example, 290 in a misconfigured "orphan mode" setup. There is no risk of this 291 happening in an NTP network with 3 or more time sources, or in a 292 properly-configured "time island" setup. 294 3.3. Questions 296 Should we reference the REFID Suggestion and I-DO proposals here? 298 Should we ask IANA to allocate a pseudo Extension Field Type of 299 0xFFFF (for example) so the proposed "I-Do" exchange can report 300 whether or not the "IPv6 REFID Hash" is supported? 302 4. The REFID sent to clients during a Leap-Smear 304 4.1. Background 306 This proposal offers a way for a system to generate a REFID that 307 indicates that the time being supplied in the NTP packet already 308 contains an amount of leap smear correction, and what that amount is. 310 4.2. Leap Smear REFID 312 RFC 5905 [RFC5905] defines the data type of NTP time values in 313 Section 6, "Data Types": 315 All NTP time values are represented in twos-complement format, 316 with bits numbered in big-endian (as described in Appendix A of 317 [RFC0791]) fashion from zero starting at the left, or high-order, 318 position. ... 320 The 32 bit signed integer seconds portion and the 32 bit unsigned 321 fractional seconds portion, or 32:32 format is: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Seconds | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Fraction | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 NTP Timestamp Format (32:32) 333 This format provides coverage for 136 years' time to a precision of 334 232 picoseconds. If a leap-second addition is being completely 335 smeared just before before the stroke of the next POSIX second then 336 the smear correction will be (0,1). [That's mathematical domain 337 range notation - how to cite it?] If this was the only way to apply 338 a leap smear correction then we could simply use an unsigned value to 339 represent the correction. But while the first popular leap smear 340 implementation applied the correction over an appropriate number of 341 hours' time before the actual leap second, so the system time was 342 again correct at the stroke of 00:00, that meant that the difference 343 between system time and UTC spent half of the duration of the smear 344 application at [.5,1) "off" of correct time. The second popular 345 implementation of the leap smear applied the first half-second 346 correction before the stroke of 00:00 for a correction range of 347 (0,.5] and the last half-second correction starting at the stroke of 348 00:00 for a [-.5,0) correction range. This also means we need a 349 signed value to represent the amount of correction. 351 The REFID of a system that is supplying smeared time to client 352 requests while leap-smear correction is active would be 254.b1.b2.b3, 353 where the three octets (b1, b2, and b3) are a 2:22 formatted value, 354 yielding 2 signed bits of integer time and 22 bits of unsigned 355 fractional subseconds, with a precision to 238 nanoseconds, or about 356 a quarter of a microsecond. Signed time is needed to implement the 357 mathematical range described in the previous paragraph. 359 [How should we cite the 2:22 notation? This is the same general 360 format that we use for NTP timestamps.] 362 [Sharon says: I suggest adding a concrete example of the scheme, so 363 that the above paragraph is easier to understand.] 365 The client is not expected to do anything with this information. 366 Indeed, the whole point of offering smeared time is that there is 367 reason to believe the clients are unable to properly handle a leap 368 second correction. In this case, clients cannot be expected to do 369 anything with data embedded in the REFID, either. However, 370 monitoring systems that use tools that show a host's system peer, 371 like the 'ntpq' and 'sntp' programs in the reference implementation, 372 [HMS: how to cite this?] can use this information to make sure that 373 clients are following a leap-smearing server and can see fairly 374 accurately what the smear is for each client. 376 Note that if an NTP server decides to offer smeared time corrections 377 to clients, it SHOULD only offer this time in response to CLIENT time 378 requests. An NTP server that is offering smeared time SHOULD NOT 379 send smeared time in any peer exchanges. Also, system that sync 380 their time via CLIENT requests SHOULD NOT be distributing time 381 (smeared or otherwise) to other systems. 383 [Sharon asks: Consider a client that doesn't know he is getting 384 smeared time (b\c he is outdated etc). How is a this client supposed 385 to know that he should not be distributing smeared time? Note that 386 its perfectly normal for a stratum 2 server that gets his time via 387 CLIENT requests from a stratum 1 server to then offer time to stratum 388 3 systems.] 390 We also note that during the application of a leap smear, the REFID 391 from a system offering smeared time cannot provide detection of a 392 timing loop. This is not expected to be a problem because time 393 server systems are not expected to make CLIENT connections with each 394 other, so they should not be receiving smeared time. [Sharon asks: I 395 don't understand this point, see my question above.] Moreso, if a 396 time server is configured to make CLIENT connections to a server that 397 offers smeared time, with the mechanism described here it can detect 398 when it is getting smeared time, and either ignore time from that 399 source, or "undo" the leap smear correction and use the corrected 400 time for that sample. 402 This proposal is not an attempt to justify servers offering leap 403 smeared time. It is only an attempt to make it easy and visible to 404 identify when a server is offering or client is receiving smeared 405 time, and provide the client a means to know the amount of smear 406 correction as of the latest successful poll. 408 4.3. Questions 410 Should we ask IANA to allocate a pseudo Extension Field Type of 411 0xFFFE (for example) so the proposed "I-Do" exchange can report 412 whether or not this server will offer leap smeared time in response 413 to CLIENT time requests, identifying the amount of correction using 414 the above REFID? 416 5. Acknowledgements 418 For the "not-you" REFID, we acknowledge useful discussions with 419 Aanchal Malhotra and Matthew Van Gundy. 421 For the IPv6 REFID, we acknowledge Dan Mahoney (and perhaps others) 422 for suggesting the idea of using an "impossible" first-octet value to 423 indicate an IPv6 refid hash. 425 For the Leap Smear REFID, we acknowledge useful discussions with 426 Juergen Perlinger. 428 6. IANA Considerations 430 This memo makes no requests of IANA. 432 7. Security Considerations 434 Many systems running NTP are configured to return responses to timing 435 queries by default. These responses contain a REFID field, which 436 generally reveals the address of the system's time source if that 437 source is an IPv4 address. This behavior can be exploited by remote 438 attackers who wish to first learn the address of a target's time 439 source, and then attack the target and/or its time source. As such, 440 the NOT-YOU REFID proposal is designed to harden NTP against these 441 attacks by limiting the amount of information leaked in the REFID 442 field. 444 Systems running NTP should reveal the identity of their system in 445 peer in their REFID only when they are on a trusted network. The 446 IPv6 REFID proposal provides one way to do this, when the system peer 447 uses addresses in the IPv6 family. 449 8. References 451 8.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 459 "Network Time Protocol Version 4: Protocol and Algorithms 460 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 461 . 463 8.2. Informative References 465 [CVE-2015-8138] 466 Van Gundy, M. and J. Gardner, "Network Time Protocol 467 Origin Timestamp Check Impersonation Vulnerability (CVE- 468 2015-8138)", in TALOS VULNERABILITY REPORT (TALOS- 469 2016-0077), 2016. 471 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 472 "Attacking the Network Time Protocol", in ISOC Network and 473 Distributed System Security Symposium 2016 (NDSS'16), 474 2016. 476 Authors' Addresses 478 Harlan Stenn 479 Network Time Foundation 480 P.O. Box 918 481 Talent, OR 97540 482 US 484 Email: stenn@nwtime.org 486 Sharon Goldberg 487 Boston University 488 111 Cummington St 489 Boston, MA 02215 490 US 492 Email: goldbe@cs.bu.edu