idnits 2.17.1 draft-ietf-ntp-port-randomization-00.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC5905, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 405 has weird spacing: '...ifornia pp. 2...' -- The document date (October 22, 2019) is 1648 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol (ntp) Working Group F. Gont 3 Internet-Draft G. Gont 4 Updates: rfc5905 (if approved) SI6 Networks 5 Intended status: Standards Track M. Lichvar 6 Expires: April 24, 2020 Red Hat 7 October 22, 2019 9 Port Randomization in the Network Time Protocol Version 4 10 draft-ietf-ntp-port-randomization-00 12 Abstract 14 The Network Time Protocol can operate in several modes. Some of 15 these modes are based on the receipt of unsolicited packets, and 16 therefore require the use of a service/well-known port as the local 17 port number. However, in the case of NTP modes where the use of a 18 service/well-known port is not required, employing such well-known/ 19 service port unnecessarily increases the ability of attackers to 20 perform blind/off-path attacks. This document formally updates 21 RFC5905, recommending the use of port randomization for those modes 22 where use of the NTP service port is not required. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 24, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Considerations About Port Randomization in NTP . . . . . . . 3 61 3.1. Mitigation Against Off-path Attacks . . . . . . . . . . . 3 62 3.2. Effects on Path Selection . . . . . . . . . . . . . . . . 4 63 3.3. Filtering of NTP traffic . . . . . . . . . . . . . . . . 4 64 3.4. Effect on NAT devices . . . . . . . . . . . . . . . . . . 5 65 3.5. Relation to Other Mitigations for Off-Path Attacks . . . 5 66 4. Update to RFC5905 . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Possible Future Work . . . . . . . . . . . . . . . . . . . . 6 68 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Network Time Protocol (NTP) is one of the oldest Internet 80 protocols, and currently specified in [RFC5905]. Since its original 81 implementation, standardization, and deployment, a number of 82 vulnerabilities have been found both in the NTP specification and in 83 some of its implementations [NTP-VULN]. Some of these 84 vulnerabilities allow for off-path/blind attacks, where an attacker 85 can send forged packets to one or both NTP peers for achieving Denial 86 of Service (DoS), time-shifts, and other undesirable outcomes. Many 87 of these attacks require the attacker to guess or know at least a 88 target NTP association, typically identified by the tuple {srcaddr, 89 srcport, dstaddr, dstport, keyid}. Some of these parameters may be 90 easily known or guessed. 92 NTP can operate in several modes. Some of these modes rely on the 93 ability of nodes to receive unsolicited packets, and therefore 94 require the use of a service/well-known port number. However, for 95 modes where the use of a service/well-known port is not required, 96 employing such well-known/service port improves the ability of an 97 attacker to perform blind/off-path attacks (since knowledge of such 98 port number is typically required for such attacks). A recent study 99 [NIST-NTP] that analyzes the port numbers employed by NTP clients 100 suggests that a considerable number of NTP clients employ the NTP 101 service/well-known port as their local port, or select predictable 102 ephemeral port numbers, thus improving the ability of attackers to 103 perform blind/off-path attacks against NTP. 105 BCP 156 [RFC6056] already recommends the randomization of transport- 106 protocol ephemeral ports. This document aligns NTP with the 107 recommendation in BCP 156 [RFC6056], by formally updating [RFC5905] 108 such that port randomization is employed for those NTP modes for 109 which the use of the NTP service port is not required. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Considerations About Port Randomization in NTP 119 The following subsections analyze a number of considerations about 120 transport-protocol port randomization when applied to NTP. 122 3.1. Mitigation Against Off-path Attacks 124 There has been a fair share of work in the area of off-path/blind 125 attacks against transport protocols and upper-layer protocols, such 126 as [RFC5927] and [RFC4953]. Whether the target of the attack is a 127 transport protocol instance (e.g., TCP connection) or an upper-layer 128 protocol instance (e.g., an application protocol instance), the 129 attacker is required to know or guess the five-tuple {Protocol, IP 130 Source Address, IP Destination Address, Source Port, Destination 131 Port} that identifies the target transport protocol instance or the 132 transport protocol instance employed by the target upper-layer 133 protocol instance. Therefore, increasing the difficulty of guessing 134 this five-tuple helps mitigate blind/off-path attacks. 136 As a result of this considerations, BCP 156 [RFC6056] recommends the 137 randomization of transport-protocol ephemeral ports. And as such, 138 this document aims to bring the NTP specification [RFC5905] in line 139 with the aforementioned recommendation. 141 We note that the use of port randomization is a transport-layer 142 mitigation against off-path/blind attacks, and does not preclude (nor 143 is it precluded by), other possible mitigations for off-path attacks 144 that might be implemented by an application protocol (e.g. 146 [I-D.ietf-ntp-data-minimization]). For instance, some of the 147 aforementioned mitigations may be ineffective against some off-path 148 attacks [NTP-FRAG] or may benefit from the additional entropy 149 provided by port randomization [NTP-security]. 151 3.2. Effects on Path Selection 153 Intermediate systems implementing the Equal-Cost Multi-Path (ECMP) 154 algorithm may select the outgoing link by computing a hash over a 155 number of values, that include the transport-protocol source port. 156 Thus, as discussed in [NTP-CHLNG], the selected client port may have 157 an influence on the measured delay and jitter values. 159 This might mean, for example, that two systems in the same network 160 that synchronize their clocks with the same NTP server might end up 161 with a significant offset between their clocks as a result of their 162 NTP samples taking paths with very different characteristics. 164 If port randomization is applied for every NTP request, requests/ 165 responses would be distributed over the different available paths, 166 including those with the smallest delay. The clock filter algorithm 167 could readily select one of such samples with lowest delays, in the 168 same way that the clock selection and clock cluster algorithms might 169 also end up selecting other time sources with smaller resulting 170 dispersion. On the other hand, if port-randomization is applied on a 171 per-association basis, in scenarios where the aforementioned ECMP 172 algorithm is employed, request/responses to the same association 173 would likely follow the same path, since the IP addresses and 174 transport port numbers employed for an association would not change. 176 Section 4 recommends NTP implementations to randomize the ephemeral 177 port number of non-symmetrical associations on a per-association 178 basis (as opposed to "per-transaction"), since this more conservative 179 approach avoids the possible negative implications of port 180 randomization on time synchronization. 182 3.3. Filtering of NTP traffic 184 In a number of scenarios (such as when mitigating DDoS attacks), a 185 network operator may want to differentiate between NTP requests sent 186 by clients, and NTP responses sent by NTP servers. If an 187 implementation employs the NTP service port for the client port 188 number, requests/responses cannot be readily differentiated by 189 inspecting the source and destination port numbers. Implementation 190 of port randomization for non-symmetrical modes allows for simple 191 differentiation of NTP requests and responses, and for the 192 enforcement of security policies that may be valuable for the 193 mitigation of DDoS attacks. 195 3.4. Effect on NAT devices 197 Some NAT devices will not translate the source port of a packet when 198 a privileged port number is employed. In networks where such NAT 199 devices are employed, use of the NTP service port for the client port 200 will essentially limit the number of hosts that may successfully 201 employ NTP client implementations. 203 In the case of NAT devices that will translate the source port even 204 when a privileged port is employed, packets reaching the external 205 realm of the NAT will not employ the NTP service port as the local 206 port, since the local port will normally be translated by the NAT 207 device possibly, but not necessarily, with a random port. 209 3.5. Relation to Other Mitigations for Off-Path Attacks 211 Ephemeral Port Randomization is a best current practice (BCP 156) 212 that helps mitigate off-path attacks at the transport-layer. It is 213 orthogonal to other possible mitigations for off-path attacks that 214 may be implemented at other layers (such as the use of timestamps in 215 NTP) which may or may not be effective against some off-path attacks 216 (see e.g. [NTP-FRAG]. This document aligns NTP with the existing 217 best current practice on ephemeral port selection, irrespective of 218 other techniques that may (and should) be implemented for mitigating 219 off-path attacks. 221 4. Update to RFC5905 223 The following text from Section 9.1 ("Peer Process Variables") of 224 [RFC5905]: 226 dstport: UDP port number of the client, ordinarily the NTP port 227 number PORT (123) assigned by the IANA. This becomes the source 228 port number in packets sent from this association. 230 is replaced with: 232 dstport: UDP port number of the client. In the case of broadcast 233 server mode (5) and symmetric modes (1 and 2), it must contain the 234 NTP port number PORT (123) assigned by the IANA. In other cases, 235 it SHOULD contain a randomized port number, as specified in 236 [RFC6056]. The value in this variable becomes the source port 237 number of packets sent from this association. 239 NOTES: 241 When port randomization is employed, the port number must be 242 randomized on a per-association basis. That is, a random port 243 number is selected when an association is first mobilized, and 244 the selected port number is expected to remain constant during 245 the life of an association. 247 On most current operating systems (that implement ephemeral 248 port randomization [RFC6056]), an NTP client may normally rely 249 on the operating system for performing port randomization. For 250 example, NTP implementations employing the Sockets API may 251 achieve port randomization by *not* specifying the local port 252 for the corresponding socket, or bind()ing the local socket to 253 the "special" port 0 (which for the Sockets API has the special 254 meaning of "any port"). connect()ing the docket will make the 255 port inaccessible by other systems (that is, only packets from 256 the specified remote socket will be received by the 257 application). 259 5. Possible Future Work 261 Port numbers could be randomized on a per-association basis, or on a 262 per-request basis. When the port number is randomized on a per- 263 association basis, a random port number is selected when an 264 association is first mobilized, and the selected port remains 265 constant during the life of the association. On the other hand, when 266 the port number is randomized on a per-request basis, each client 267 request will (statistically) employ a different ephemeral port for 268 each request. As discussed in Section 3, varying the port number 269 across requests may impact the time quality achieved with NTP. As a 270 result, this document recommends the conservative approach of 271 randomizing port numbers on a per-association basis (as opposed to a 272 "per-transaction" basis). The possibility of randomizing port 273 numbers on a per-transaction may be subject of future work, and is 274 not recommended by this document. 276 6. Implementation Status 278 [RFC Editor: Please remove this section before publication of this 279 document as an RFC.] 281 This section records the status of known implementations of the 282 protocol defined by this specification at the time of posting of this 283 Internet-Draft, and is based on a proposal described in [RFC7942]. 284 The description of implementations in this section is intended to 285 assist the IETF in its decision processes in progressing drafts to 286 RFCs. Please note that the listing of any individual implementation 287 here does not imply endorsement by the IETF. Furthermore, no effort 288 has been spent to verify the information presented here that was 289 supplied by IETF contributors. This is not intended as, and must not 290 be construed to be, a catalog of available implementations or their 291 features. Readers are advised to note that other implementations may 292 exist. 294 OpenNTPD: 295 [OpenNTPD] has never explicitly set the local port of NTP clients, 296 and thus employs the ephemeral port selection algorithm 297 implemented by the operating system. Thus, on all operating 298 systems that implement port randomization (such as current 299 versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ 300 port randomization for client ports. 302 chrony: 303 [chrony] has never explicitly set the local port of NTP clients, 304 and thus employs the ephemeral port selection algorithm 305 implemented by the operating system. Thus, on all operating 306 systems that implement port randomization (such as current 307 versions of OpenBSD, Linux, and FreeBSD), chrony will employ port 308 randomization for client ports. 310 nwtime.org's sntp client: 311 sntp does not explicitly set the local port, and thus employs the 312 ephemeral port selection algorithm implemented by the operating 313 system. Thus, on all operating systems that implement port 314 randomization (such as current versions of OpenBSD, Linux, and 315 FreeBSD), it will employ port randomization for client ports. 317 7. IANA Considerations 319 There are no IANA registries within this document. The RFC-Editor 320 can remove this section before publication of this document as an 321 RFC. 323 8. Security Considerations 325 The security implications of predictable numeric identifiers 326 [I-D.gont-predictable-numeric-ids] (and of predictable transport- 327 protocol port numbers [RFC6056] in particular) have been known for a 328 long time now. However, the NTP specification has traditionally 329 followed a pattern of employing common settings and code even when 330 not strictly necessary, which at times has resulted in negative 331 security and privacy implications (see e.g. 332 [I-D.ietf-ntp-data-minimization]). The use of the NTP service port 333 (123) for the srcport and dstport variables is not required for all 334 operating modes, and such unnecessary usage comes at the expense of 335 reducing the amount of work required for an attacker to successfully 336 perform off-path/blind attacks against NTP. Therefore, this document 337 formally updates [RFC5905], recommending the use of transport- 338 protocol port randomization when use of the NTP service port is not 339 required. 341 This issue has been tracked by US-CERT with VU#597821, and has been 342 assigned CVE-2019-11331. 344 9. Acknowledgments 346 Watson Ladd raised the problem of DDoS mitigation when the NTP 347 service port is employed as the client port (discussed in Section 3.3 348 of this document). 350 The authors would like to thank (in alphabetical order) Ivan Arce, 351 Todd Glassey, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E. 352 Miller, Dieter Sibold, Steven Sommars, and Ulrich Windl, for 353 providing valuable comments on earlier versions of this document. 355 The authors would like to thank Harlan Stenn for answering questions 356 about nwtime.org's NTP implementation. 358 Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for 359 their love and support. 361 10. References 363 10.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 371 "Network Time Protocol Version 4: Protocol and Algorithms 372 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 373 . 375 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 376 Protocol Port Randomization", BCP 156, RFC 6056, 377 DOI 10.17487/RFC6056, January 2011, 378 . 380 10.2. Informative References 382 [chrony] "chrony", . 384 [I-D.gont-predictable-numeric-ids] 385 Gont, F. and I. Arce, "Security and Privacy Implications 386 of Numeric Identifiers Employed in Network Protocols", 387 draft-gont-predictable-numeric-ids-03 (work in progress), 388 March 2019. 390 [I-D.ietf-ntp-data-minimization] 391 Franke, D. and A. Malhotra, "NTP Client Data 392 Minimization", draft-ietf-ntp-data-minimization-04 (work 393 in progress), March 2019. 395 [NIST-NTP] 396 Sherman, J. and J. Levine, "Usage Analysis of the NIST 397 Internet Time Service", Journal of Research of the 398 National Institute of Standards and Technology Volume 121, 399 March 2016, . 401 [NTP-CHLNG] 402 Sommars, S., "Challenges in Time Transfer Using the 403 Network Time Protocol (NTP)", Proceedings of the 48th 404 Annual Precise Time and Time Interval Systems and 405 Applications Meeting, Monterey, California pp. 271-290, 406 January 2017, . 409 [NTP-FRAG] 410 Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 411 "Attacking the Network Time Protocol", NDSS'17, San Diego, 412 CA. Feb 2017, 2017, 413 . 415 [NTP-security] 416 Malhotra, A., Van Gundy, M., Varia, V., Kennedy, H., 417 Gardner, J., and S. Goldberg, "The Security of NTP's 418 Datagram Protocol", Cryptology ePrint Archive Report 419 2016/1006, 2016, . 421 [NTP-VULN] 422 Network Time Foundation, "Security Notice", Network Time 423 Foundation's NTP Support Wiki , 424 . 426 [OpenNTPD] 427 "OpenNTPD Project", . 429 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 430 RFC 4953, DOI 10.17487/RFC4953, July 2007, 431 . 433 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 434 DOI 10.17487/RFC5927, July 2010, 435 . 437 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 438 Code: The Implementation Status Section", BCP 205, 439 RFC 7942, DOI 10.17487/RFC7942, July 2016, 440 . 442 Authors' Addresses 444 Fernando Gont 445 SI6 Networks 446 Evaristo Carriego 2644 447 Haedo, Provincia de Buenos Aires 1706 448 Argentina 450 Phone: +54 11 4650 8472 451 Email: fgont@si6networks.com 452 URI: https://www.si6networks.com 454 Guillermo Gont 455 SI6 Networks 456 Evaristo Carriego 2644 457 Haedo, Provincia de Buenos Aires 1706 458 Argentina 460 Phone: +54 11 4650 8472 461 Email: ggont@si6networks.com 462 URI: https://www.si6networks.com 464 Miroslav Lichvar 465 Red Hat 466 Purkynova 115 467 Brno 612 00 468 Czech Republic 470 Email: mlichvar@redhat.com