idnits 2.17.1 draft-stenn-ntp-suggest-refid-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 : ---------------------------------------------------------------------------- == 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: 'RFC7384' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'DRAFT-I-DO' is defined on line 296, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7384 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 March 25, 2019 5 Expires: September 26, 2019 7 Network Time Protocol Suggested REFID Extension Field 8 draft-stenn-ntp-suggest-refid-05 10 Abstract 12 NTP's Reference ID, or REFID, identifies the source of time in a 13 timestamp or time packet. In NTP packets sent over the network the 14 REFID is used to identify the "system peer", and in the long-term 15 general case its fundamental purpose is to prevent a one-degree 16 timing loop. Each instance of NTP decides for itself what REFID it 17 will put in its outgoing packets, and there is currently no way for 18 an external time source to tell or recommend this value in the case 19 where that external time source is selected as the "system peer." 21 The SUGGESTED-REFID NTP Extension Field proposal is a backward- 22 compatible way for a time source to tell its peers or clients "If you 23 use me as your system peer, use this nonce as your REFID." 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 26, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. The REFID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. The Suggested REFID Extension Field . . . . . . . . . . . . . 4 63 4. Generating and Sending a Nonce as the Suggested REFID 64 Extension Field . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Remembering a Nonce Suggested REFID Extension Field . . . . . 5 66 6. The Suggested REFID Extension Field and Leap Smear REFIDs . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 NTP has been widely used through several revisions, with the latest 78 being RFC 5905 [RFC5905]. A core component of the protocol and the 79 algorithms is the Reference ID, or REFID, which is used to identify 80 the time source. Traditionally, when the source of time was another 81 system the REFID was the IPv4 address of that other system. If the 82 remote system was using IPv6 for its connection, a 4 octet digest 83 value of the IPv6 address was used. The general case core purpose of 84 the REFID is to prevent a one-degree timing loop (where if A has 85 several timing sources that include B, if B decides to get its time 86 from A we don't want A then deciding to get its time from B). The 87 REFID is considered to be "public data" and is a vital core-component 88 of the base NTP packet. In an increasingly hostile Internet, 89 knowledge of a system's time source is abusable information. If a 90 system's REFID is the IPv4 address of its system peer, an attacker 91 can try to use that information to send spoofed time packets to 92 either or both the target or the target's server, attempting to cause 93 a disruption in time service. There is also a clear use-case for 94 having a special REFID for use if systems are exchanging leap-smeared 95 time. This proposal is a backward-compatible way for a time source 96 to tell its peers or clients "If you use me as your system peer, use 97 this nonce as your REFID." This nonce, a Suggested REFID, SHOULD be 98 untraceable to the sending system. When used to hide the identity of 99 a server, if the receiving system uses this Suggested REFID nonce 100 instead of the IPv4 address as its REFID, this type of attack and 101 information disclosure is prevented. When used to indicate that a 102 system is either offering leap-smeared time or is synchronized to a 103 leap-smeared time source, this information can be used to prevent 104 unwanted synchronization to a source that is not offering the 105 "flavor" of time we want, and, in the case where a leap smear 106 correction continues into the next day, the second half of a leap 107 smear correction can be applied in the expected manner. 109 This SUGGESTED-REFID NTP Extension Field proposal is a simple, clean, 110 backward-compatible way for an external time soure to request that 111 the receiving system use the provided nonce in the case where the 112 receiving system uses the sending system as its system peer. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. The REFID 122 The core reason for the REFID in the NTP Protocol is to prevent a 123 timing loop of degree 1. Put another way, if servers A and B are 124 exchanging time with each other and server B decides to follow A as 125 its system peer, the REFID that B will use must be able to identify 126 server A. The interpretation of a REFID is based on the stratum, as 127 documented in RFC 5905 [RFC5905], section 7.3, "Packet Header 128 Variables". At Stratum 2+, which will be the case if servers A and B 129 are exchanging packets over IPv4, if server B follows A, then B will 130 have A's IPv4 address as its REFID. When A asks B for its time, A 131 will see that B is synchronized to A because B will tell A that its 132 REFID is A's IPv4 address, so when A sees its IP address as B's 133 REFID, A knows that if it were to follow B for its time then there 134 would be a timing loop. In this case, A will not select B as a 135 potential source of time. 137 Another related use case for the REFID centers around the increasing 138 use of leap-smearing time servers when the insertion (or any eventual 139 deleiton) of a leap second occurs. It is critical that operators and 140 client systems be able to identify when a server is offering leap- 141 smeared time. Futhermore, with the current practice of smearing the 142 insertion of a leap second starting at noon UTC on the day of the 143 leap event and completing the smear at noon UTC on the day after the 144 leap event, a server that is operating during a leap smear event must 145 be able to immediately identify if it should respond with either 146 correct or leap-smeared time. 148 3. The Suggested REFID Extension Field 150 Since there is no way in the base NTP packet for "this" instance of 151 an NTP server to tell the "other" instance what REFID it should use 152 if the "other" instance decides to use "this" instance as its system 153 peer, the best available way to convey this information is via an 154 extension field. 156 0 1 2 3 157 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 158 +---------------+---------------+-------------------------------+ 159 | Field Type | Field Length | 160 +-------------------------------+-------------------------------+ 161 | Suggested REFID | 162 +---------------------------------------------------------------+ 164 NTP Extension Field: REFID Suggestion 166 Field Type: TBD (Recommendation for IANA: 0x0006 (Suggested REFID)) 168 Field Length: 0x0008 170 Suggested REFID: The 4 octets of the suggested REFID. Random nonce 171 REFID values SHOULD be 0xFDxxxxxx, where the bottom 3 octets SHOULD 172 be random values. 174 Examples: When decoded as an IPv4 address, a random nonce suggested 175 REFID would decode as 253.0.0.0 thru 253.255.255.255. 177 4. Generating and Sending a Nonce as the Suggested REFID Extension 178 Field 180 A system that decides to send a nonce as a Suggested REFID extension 181 field SHOULD generate a new Suggested REFID nonce for each new 182 association. It MAY generate a new Suggested REFID nonce for any 183 association in any response. In addition to remembering the IP-based 184 REFID, the sender MUST also remember its most-recent Suggested REFID 185 nonce. 187 Since the core NTPv4 and earlier protocols do not contain any way to 188 tell the recipient what to use as a REFID and RFC 5905 [RFC5905] uses 189 the IPv4 address of the sender as the REFID if the association is 190 effected over an IPv4 connection, this means that an attacker can 191 simply send an NTP client request to a server knowing that server's 192 system peer will be returned as the REFID in the response packet. At 193 this point, an attacker can, if that REFID is an IPv4 address, begin 194 to launch attacks at the target forging the putative IP of the 195 target's time source, or the attacker can start forging packets to 196 the putative time server claiming to be from the target, in an 197 attempt to cause the time server to limit or deny time service to the 198 target. 200 Using a nonce for the REFID that is only recognized by the sending 201 machine effectively prevents this type of attack. 203 If servers S1, S2, and S3 are all exchanging time with each other and 204 are all using the Suggested REFID mechanism, there is a 3 in 205 16,777,216 (2^24) chance that two different servers in the same group 206 will happen to choose the same nonce, and that would produce a false- 207 positive timing loop detection. If a nonce Suggested REFID is never 208 changed, this false-positive condition will occur for potentially a 209 long time. This small risk can be reduced by periodically generating 210 a new Suggested REFID. 212 5. Remembering a Nonce Suggested REFID Extension Field 214 An NTP server keeps track of the IP address it uses to talk to its 215 peers. If an NTP server chooses to send a Suggested REFID to an 216 associated peer, the server MUST remember this value. When checking 217 for a timing loop, the Suggested REFID must also be included in the 218 list of tested REFID values. 220 A set of NTP servers that are acting as a group of time servers 221 SHOULD be using peer associations (NTP mode 1 and 2 packets), and 222 SHOULD NOT be using client/server (NTP mode 3 and 4) exchanges. 223 Nevertheless, implementors should be aware that the recommendation 224 against using client/server associations for time groups may be 225 ignored, and should be conscious of the choices they make and the 226 configuration options they offer in order to accomodate (or at least 227 document) this situation. 229 6. The Suggested REFID Extension Field and Leap Smear REFIDs 231 The Suggested REFID can play an important part when a server has a 232 client population that receives leap-smeared time. 234 The current preferred behavior for servers that offer leap-smeared 235 time is to offer leap-smeared time in response to appropriate client 236 (mode 3) requests. There are two competing forces at play during 237 this time: 239 - Clients that want correct time should get correct time. 241 - Clients that want leap-smeared time should get leap-smeared time. 243 An additional complication is that a leap-second insertion event 244 begins at noon UTC, when the Leap Indicator is 1, but the smear is 245 only halfway applied at midnight UTC, when the Leap Indicator changes 246 back to 0. There is no simple way for the client to let its 247 server(s) know that it is using leap-smeared time. 249 One simple way for the client to let its server(s) know that it is 250 using and wants leap-smeared time is for the client to use a Leap 251 Smear REFID [DRAFT-LEAP-SMEAR-REFID] in its client (mode 3) requests 252 during the entire leap smear period. 254 7. Acknowledgements 256 The author wishes to acknowledge the contributions of Martin Burnicki 257 and Sam Weiler. 259 8. IANA Considerations 261 This memo requests IANA to allocate NTP Extension Field Type 0x0006 262 (Suggested REFID) for this proposal. 264 9. Security Considerations 266 Adopting this proposal will provide a much needed mechanism by which 267 cooperating systems can agree on a less trackable and less 268 identifiable nonce for the REFID. It will also provide a means to 269 properly and better handle leap-smearing events with populations 270 where some clients want correct time and other clients want leap- 271 smeared time, thus enabling better time synchronization. 273 No reports of adverse consequences of adopting this proposal have 274 been received. 276 10. References 278 10.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 286 "Network Time Protocol Version 4: Protocol and Algorithms 287 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 288 . 290 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 291 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 292 October 2014, . 294 10.2. Informative References 296 [DRAFT-I-DO] 297 Stenn, H., "draft-stenn-ntp-i-do", 2018. 299 [DRAFT-LEAP-SMEAR-REFID] 300 Stenn, H., "draft-stenn-ntp-leap-smear-refid", 2018. 302 Author's Address 304 Harlan Stenn 305 Network Time Foundation 306 P.O. Box 918 307 Talent, OR 97540 308 US 310 Email: stenn@nwtime.org