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