idnits 2.17.1 draft-ietf-ntp-refid-updates-04.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. == There are 1 instance 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 (October 4, 2018) is 2031 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 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: April 7, 2019 Boston University 6 October 4, 2018 8 Network Time Protocol REFID Updates 9 draft-ietf-ntp-refid-updates-04 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 two recognized shortcomings to this approach, 18 and this proposal addresses them. One is that knowledge of the 19 system peer is "abusable" information and should not be generally 20 available. The second is that the four octet hash of the IPv6 21 address looks very much like an IPv4 address, and this is confusing. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 7, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. The REFID . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. IPv6 REFID . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. The NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 5 65 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6 67 3.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 1.1. The REFID 80 The interpretation of a REFID is based on the stratum, as documented 81 in RFC 5905 [RFC5905], section 7.3, "Packet Header Variables". The 82 core reason for the REFID in the NTP Protocol is to prevent a degree- 83 one timing loop, where server B decides to follow A as its time 84 source, and A then decides to follow B as its time source. 86 At Stratum 2+, which will be the case if two servers A and B are 87 exchanging timing information, then if server B follows A as its time 88 source, A's address will be B's REFID. When A uses IPv4, the default 89 REFID is A's IPv4 address. When A uses IPv6, the default REFID is a 90 four-octet digest of A's IPv6 address. Now, if A queries B for its 91 time, then A will learn that B is using A as its time source by 92 observing A's address in the REFID field of the response packet sent 93 by B. Thus, A will not select B as a potential time source, as this 94 would cause a timing loop. 96 1.2. NOT-YOU REFID 98 The traditional REFID mechanism, however, also allows a third-party C 99 to learn that A is the time source that is being used by B. When A 100 is using IPv4, C can learn this by querying B for its time, and 101 observing that the REFID in B's response is the IPv4 address of A. 102 Meanwhile, when A is using IPv6, then C can again query B for its 103 time, and then can use an offline dictionary attack to attempt to 104 determine the IPv6 address that corresponds to the digest value in 105 the response sent by B. C could construct the necessary dictionary 106 by compiling a list of publicly accessible IPv6 servers. Remote 107 attackers can use this technique to attempt to identify the time 108 sources used by a target, and then send spoofed packets to the target 109 or its time source in an attempt to disrupt time service, as was done 110 e.g., in [NDSS16] or [CVE-2015-8138]. 112 The REFID thus unnecessarily leaks information about a target's time 113 server to remote attackers. The best way to mitigate this 114 vulnerability is to decouple the IP address of the time source from 115 the REFID. To do this, a system can use an otherwise-impossible 116 value for its REFID, called the "not-you" value, when it believes 117 that a querying system is not its time source. 119 The NOT-YOU REFID proposal is backwards-compatible. It can be 120 implemented by one peer in an NTP association without any changes to 121 the other peer. 123 The NOT-YOU REFID proposal does have a small risk, in that a system 124 that might return NOT-YOU does not have perfect information and it is 125 possible that the remote system peer is contacting "us" via a 126 different network interface. In this case, the remote system might 127 choose us as their system peer, and a degree-one timing loop will 128 occur. In this case, however, the two systems will spiral into 129 worsening stratum positions with increasing root distances, and 130 eventually the loop will break. If any other systems are available 131 as time servers, one of them may become the new system peer. 132 However, unless or until this happens the two spiraling systems will 133 have degraded time quality. 135 1.3. IPv6 REFID 137 In an environment where all time queries made to a server can be 138 trusted, an operator might well choose to expose the real REFID. RFC 139 5905 [RFC5905], section 7.3, "Packet Header Variables", explains how 140 a remote system peer is converted to a REFID. It says: 142 If using the IPv4 address family, the identifier is the four-octet 143 IPv4 address. If using the IPv6 family, it is the first four 144 octets of the MD5 hash of the IPv6 address. ... 146 However, the MD5 hash of an IPv6 address often looks like a valid 147 IPv4 address. When this happens, an operator cannot tell if the 148 REFID refers to an IPv6 address or and IPv4. Specifically, the NTP 149 Project has received a report where the generated IPv6 hash decoded 150 to the IPv4 address of a different machine on the system peer's 151 network. 153 This proposal offers a way for a system to generate a REFID for a 154 IPv6 system peer that does not conflict with an IPv4-based REFID. 156 This proposal is not fully backwards-compatible. It SHOULD be 157 implemented by both peers in an NTP association. In the scenario 158 where A and B are peering using IPv6, where A is the system peer and 159 does not understand IPv6 REFID, and B is subordinate and is using 160 IPv6 REFID, A will not be able to determine that B is using A as its 161 system peer and a degree-one timing loop can form. 163 If both peers implement the IPv6 REFID this situation cannot happen. 165 [If at least one of the peers implements the proposed I-DO protocol 166 this situation cannot happen.] 168 1.4. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 2. The NOT-YOU REFID 176 2.1. Proposal 178 When enabled, this proposal allows the one-degree loop detection to 179 work and useful diagnostic information to be provided to trusted 180 partners while keeping potentially abusable information from being 181 disclosed to ostensibly uninterested parties. It does this by 182 returning the normal REFID to queries that come from trusted 183 addresses or from an address that the current system believes is its 184 time source (aka its "system peer"), and otherwise returning one of 185 two special IP addresses that is interpreted to mean "not you". The 186 "not you" IP addresses are 127.127.127.127 and 127.127.127.128. If 187 an IPv6 query is received from an address whose four-octet hash 188 equals one of these two addresses and we believe the querying host is 189 not our system peer, the other NOT-YOU address is returned as the 190 REFID. 192 This mechanism is correct and transparent when the system responding 193 with a NOT-YOU can accurately detect when it's getting a timing query 194 from its system peer. A querying system that uses IPv4 continues to 195 check that its IPv4 address does not appear in the REFID before 196 deciding whether to take time from the current system. A querying 197 system that uses IPv6 continues to check that the four-octet hash of 198 its IPv6 address does not appear in the REFID before deciding whether 199 to take time from the current system. However... 201 Use of the NOT-YOU REFID proposal will hide the current system's 202 system peer from querying systems that the current system believes 203 are not the current system's system peer. Should the current system 204 return the "not you" REFID to a query from its system peer, for 205 example in the case where the system peer sends its query from an 206 unexpected IP address, a one-degree timing loop can occur. Put 207 another way, the responding system has imperfect knowledge about 208 whether or not the sender is its system peer and there are cases 209 where it will offer a NOT-YOU response to its system peer, which can 210 then produce a degree-one timing loop. 212 Note that this mechanism fully supports degree-one loop detection in 213 the case where the responding NOT-YOU system can accurately detect 214 when it's getting a request from its system peer, and otherwise 215 provides the most basic diagnostic information to third parties. 217 3. Augmenting the IPv6 REFID Hash 219 3.1. Background 221 In a trusted network, the S2+ REFID is generated based on the network 222 system peer. RFC 5905 [RFC5905] says: 224 If using the IPv4 address family, the identifier is the four-octet 225 IPv4 address. If using the IPv6 family, it is the first four 226 octets of the MD5 hash of the IPv6 address. ... 228 This means that the IPv4 representation of the IPv6 hash would be: 229 b1.b2.b3.b4 . This proposal is that the system MAY also use 230 255.b2.b3.b4 as its REFID. This reduces the risk of ambiguity, since 231 addresses beginning with 255 are "reserved", and thus will not 232 collide with valid IPv4 on the network. 234 When using the REFID to check for a timing loop for an IPv6 235 association, if the code that checks the first four-octets of the 236 hash fails to match then the code must check again, using 0xFF as the 237 first octet of the hash. 239 3.2. Potential Problems 241 There is a 1 in 16,777,216 chance that the REFID hashes of two IPv6 242 addresses will be identical, producing a false-positive loop 243 detection. With a sufficient number of servers, the risk of this 244 problem becomes a non-issue. [The use of the NOT-YOU REFID and/or 245 the proposed "REFID Suggestion" or "I-DO" extension fields are ways 246 to mitigate this potential situation.] 248 Unrealistically, if only two instances of NTP are communicating via 249 IPv6 and system A implements this new IPv6 REFID hash and system B 250 does not, system B will not be able to detect this loop condition. 251 In this case, the two machines will slowly increase their Stratum 252 until they reach S16 and become unsynchronized. This situation is 253 considered to be unrealistic because, for this to happen, each system 254 would have to have only the other system available as a time source, 255 for example, in a misconfigured "orphan mode" setup. There is no 256 risk of this happening in an NTP network with 3 or more time sources, 257 or in a properly-configured "time island" setup. 259 3.3. Questions 261 Should we reference the REFID Suggestion and I-DO proposals here? 263 4. Acknowledgements 265 For the "not-you" REFID, we acknowledge useful discussions with 266 Aanchal Malhotra and Matthew Van Gundy. 268 For the IPv6 REFID, we acknowledge Dan Mahoney (and perhaps others) 269 for suggesting the idea of using an "impossible" first-octet value to 270 indicate an IPv6 refid hash. 272 5. IANA Considerations 274 This memo requests IANA to allocate a pseudo Extension Field Type of 275 0xFFFF so the proposed "I-Do" exchange can report whether or not the 276 "IPv6 REFID Hash" is supported. 278 6. Security Considerations 280 Many systems running NTP are configured to return responses to timing 281 queries by default. These responses contain a REFID field, which 282 generally reveals the address of the system's time source if that 283 source is an IPv4 address. This behavior can be exploited by remote 284 attackers who wish to first learn the address of a target's time 285 source, and then attack the target and/or its time source. As such, 286 the "not-you" REFID proposal is designed to harden NTP against these 287 attacks by limiting the amount of information leaked in the REFID 288 field. 290 Systems running NTP should reveal the identity of their system in 291 peer in their REFID only when they are on a trusted network. The 292 IPv6 REFID proposal provides one way to do this, when the system peer 293 uses addresses in the IPv6 family. 295 7. References 297 7.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 305 "Network Time Protocol Version 4: Protocol and Algorithms 306 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 307 . 309 7.2. Informative References 311 [CVE-2015-8138] 312 Van Gundy, M. and J. Gardner, "Network Time Protocol 313 Origin Timestamp Check Impersonation Vulnerability (CVE- 314 2015-8138)", in TALOS VULNERABILITY REPORT (TALOS- 315 2016-0077), 2016. 317 [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 318 "Attacking the Network Time Protocol", in ISOC Network and 319 Distributed System Security Symposium 2016 (NDSS'16), 320 2016. 322 Authors' Addresses 324 Harlan Stenn 325 Network Time Foundation 326 P.O. Box 918 327 Talent, OR 97540 328 US 330 Email: stenn@nwtime.org 331 Sharon Goldberg 332 Boston University 333 111 Cummington St 334 Boston, MA 02215 335 US 337 Email: goldbe@cs.bu.edu