idnits 2.17.1 draft-ietf-ntp-port-randomization-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 398 has weird spacing: '...ifornia pp. 2...' (Using the creation date from RFC5905, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 15, 2020) is 1313 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) == Outdated reference: A later version (-12) exists of draft-irtf-pearg-numeric-ids-generation-03 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: 5905 (if approved) SI6 Networks 5 Intended status: Standards Track M. Lichvar 6 Expires: March 19, 2021 Red Hat 7 September 15, 2020 9 Port Randomization in the Network Time Protocol Version 4 10 draft-ietf-ntp-port-randomization-06 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 well-known port as the local port 17 number. However, in the case of NTP modes where the use of a well- 18 known port is not required, employing such well-known port 19 unnecessarily increases the ability of attackers to perform blind/ 20 off-path attacks. This document formally updates RFC5905, 21 recommending the use of transport-protocol ephemeral port 22 randomization for those modes where use of the NTP well-known port is 23 not required. 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 March 19, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Considerations About Port Randomization in NTP . . . . . . . 3 62 3.1. Mitigation Against Off-path Attacks . . . . . . . . . . . 3 63 3.2. Effects on Path Selection . . . . . . . . . . . . . . . . 4 64 3.3. Filtering of NTP traffic . . . . . . . . . . . . . . . . 4 65 3.4. Effect on NAT devices . . . . . . . . . . . . . . . . . . 5 66 3.5. Relation to Other Mitigations for Off-Path Attacks . . . 5 67 4. Update to RFC5905 . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.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, or 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} (see section 9.1 of [RFC5905]). 90 Some of these parameters may be 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 the NTP well-known port (123). However, for modes 95 where the use of a well-known port is not required, employing the NTP 96 well-known port improves the ability of an attacker to perform blind/ 97 off-path attacks (since knowledge of the port numbers is typically 98 required for such attacks). A recent study [NIST-NTP] that analyzes 99 the port numbers employed by NTP clients suggests that a considerable 100 number of NTP clients employ the NTP well-known port as their local 101 port, or select predictable ephemeral port numbers, thus improving 102 the ability of attackers to perform blind/off-path attacks against 103 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 well-known port is not needed. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. Considerations About Port Randomization in NTP 121 The following subsections analyze a number of considerations about 122 transport-protocol ephemeral port randomization when applied to NTP. 124 3.1. Mitigation Against Off-path Attacks 126 There has been a fair share of work in the area of off-path/blind 127 attacks against transport protocols and upper-layer protocols, such 128 as [RFC5927] and [RFC4953]. Whether the target of the attack is a 129 transport protocol instance (e.g., TCP connection) or an upper-layer 130 protocol instance (e.g., an application protocol instance), the 131 attacker is required to know or guess the five-tuple {Protocol, IP 132 Source Address, IP Destination Address, Source Port, Destination 133 Port} that identifies the target transport protocol instance or the 134 transport protocol instance employed by the target upper-layer 135 protocol instance. Therefore, increasing the difficulty of guessing 136 this five-tuple helps mitigate blind/off-path attacks. 138 As a result of these considerations, BCP 156 [RFC6056] recommends the 139 randomization of transport-protocol ephemeral ports. Thus, this 140 document aims to bring the NTP specification [RFC5905] in line with 141 the aforementioned recommendation. 143 We note that the use of port randomization is a transport-layer 144 mitigation against off-path/blind attacks, and does not preclude (nor 145 is it precluded by) other possible mitigations for off-path attacks 146 that might be implemented by an application protocol (e.g. 147 [I-D.ietf-ntp-data-minimization]). For instance, some of the 148 aforementioned mitigations may be ineffective against some off-path 149 attacks [NTP-FRAG] or may benefit from the additional entropy 150 provided by port randomization [NTP-security]. 152 3.2. Effects on Path Selection 154 Intermediate systems implementing the Equal-Cost Multi-Path (ECMP) 155 algorithm may select the outgoing link by computing a hash over a 156 number of values, that include the transport-protocol source port. 157 Thus, as discussed in [NTP-CHLNG], the selected client port may have 158 an influence on the measured offset and delay. 160 If the source port is changed with each request, packets in different 161 exchanges will be more likely to take different paths, which could 162 cause the measurements to be less stable and have a negative impact 163 on the stability of the clock. 165 Network paths to/from a given server are less likely to change 166 between requests if port randomization is applied on a per- 167 association basis. This approach minimizes the impact on the 168 stability of NTP measurements, but may cause different clients in the 169 same network synchronized to the same NTP server to have a 170 significant stable offset between their clocks due to their NTP 171 exchanges consistently taking different paths with different 172 asymmetry in the network delay. 174 Section 4 recommends NTP implementations to randomize the ephemeral 175 port number of client/server associations. The choice of whether to 176 randomize the port number on a per-association or a per-request basis 177 is left to the implementation. 179 3.3. Filtering of NTP traffic 181 In a number of scenarios (such as when mitigating DDoS attacks), a 182 network operator may want to differentiate between NTP requests sent 183 by clients, and NTP responses sent by NTP servers. If an 184 implementation employs the NTP well-known port for the client port 185 number, requests/responses cannot be readily differentiated by 186 inspecting the source and destination port numbers. Implementation 187 of port randomization for non-symmetrical modes allows for simple 188 differentiation of NTP requests and responses, and for the 189 enforcement of security policies that may be valuable for the 190 mitigation of DDoS attacks, when all NTP clients in a given network 191 employ port randomization. 193 3.4. Effect on NAT devices 195 Some NAT devices will not translate the source port of a packet when 196 a privileged port number is employed. In networks where such NAT 197 devices are employed, use of the NTP well-known port for the client 198 port will essentially limit the number of hosts that may successfully 199 employ NTP client implementations. 201 In the case of NAT devices that will translate the source port even 202 when a privileged port is employed, packets reaching the external 203 realm of the NAT will not employ the NTP well-known port as the local 204 port, since the local port will normally be translated by the NAT 205 device possibly, but not necessarily, with a random port. 207 3.5. Relation to Other Mitigations for Off-Path Attacks 209 Transport-protocol ephemeral port randomization is a best current 210 practice (BCP 156) that helps mitigate off-path attacks at the 211 transport-layer. It is orthogonal to other possible mitigations for 212 off-path attacks that may be implemented at other layers (such as the 213 use of timestamps in NTP) which may or may not be effective against 214 some off-path attacks (see e.g. [NTP-FRAG]. This document aligns 215 NTP with the existing best current practice on ephemeral port 216 selection, irrespective of other techniques that may (and should) be 217 implemented for mitigating off-path attacks. 219 4. Update to RFC5905 221 The following text from Section 9.1 ("Peer Process Variables") of 222 [RFC5905]: 224 dstport: UDP port number of the client, ordinarily the NTP port 225 number PORT (123) assigned by the IANA. This becomes the source 226 port number in packets sent from this association. 228 is replaced with: 230 dstport: UDP port number of the client. In the case of broadcast 231 server mode (5) and symmetric modes (1 and 2), it SHOULD contain 232 the NTP port number PORT (123) assigned by the IANA. In the 233 client mode (3), it SHOULD contain a randomized port number, as 234 specified in [RFC6056]. The value in this variable becomes the 235 source port number of packets sent from this association. The 236 randomized port number SHOULD NOT be shared with other 237 associations. 239 If a client implementation performs ephemeral port randomization 240 on a per-request basis, it SHOULD close the corresponding socket/ 241 port after each request/response exchange. In order to prevent 242 duplicate or delayed server packets from eliciting ICMP port 243 unreachable error messages at the client, the client MAY wait for 244 more responses from the server for a specific period of time (e.g. 245 3 seconds) before closing the UDP socket/port. 247 NOTES: 248 The choice of whether to randomize the ephemeral port number on 249 a per-request or a per-association basis is left to the 250 implementation, and should consider the possible effects on 251 path selection along with its possible impact on time 252 measurement. 254 On most current operating systems, which implement ephemeral 255 port randomization [RFC6056], an NTP client may normally rely 256 on the operating system to perform ephemeral port 257 randomization. For example, NTP implementations using POSIX 258 sockets may achieve ephemeral port randomization by *not* 259 binding the socket with the bind() function, or binding it to 260 port 0, which has a special meaning of "any port". connect()ing 261 the socket will make the port inaccessible by other systems 262 (that is, only packets from the specified remote socket will be 263 received by the application). 265 5. Implementation Status 267 [RFC Editor: Please remove this section before publication of this 268 document as an RFC.] 270 This section records the status of known implementations of the 271 protocol defined by this specification at the time of posting of this 272 Internet-Draft, and is based on a proposal described in [RFC7942]. 273 The description of implementations in this section is intended to 274 assist the IETF in its decision processes in progressing drafts to 275 RFCs. Please note that the listing of any individual implementation 276 here does not imply endorsement by the IETF. Furthermore, no effort 277 has been spent to verify the information presented here that was 278 supplied by IETF contributors. This is not intended as, and must not 279 be construed to be, a catalog of available implementations or their 280 features. Readers are advised to note that other implementations may 281 exist. 283 OpenNTPD: 284 [OpenNTPD] has never explicitly set the local port of NTP clients, 285 and thus employs the ephemeral port selection algorithm 286 implemented by the operating system. Thus, on all operating 287 systems that implement port randomization (such as current 288 versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ 289 port randomization for client ports. 291 chrony: 292 [chrony] by default does not set the local client port, and thus 293 employs the ephemeral port selection algorithm implemented by the 294 operating system. Thus, on all operating systems that implement 295 port randomization (such as current versions of OpenBSD, Linux, 296 and FreeBSD), chrony will employ port randomization for client 297 ports. 299 nwtime.org's sntp client: 300 sntp does not explicitly set the local port, and thus employs the 301 ephemeral port selection algorithm implemented by the operating 302 system. Thus, on all operating systems that implement port 303 randomization (such as current versions of OpenBSD, Linux, and 304 FreeBSD), it will employ port randomization for client ports. 306 6. IANA Considerations 308 There are no IANA registries within this document. The RFC-Editor 309 can remove this section before publication of this document as an 310 RFC. 312 7. Security Considerations 314 The security implications of predictable numeric identifiers 315 [I-D.irtf-pearg-numeric-ids-generation] (and of predictable 316 transport-protocol port numbers [RFC6056] in particular) have been 317 known for a long time now. However, the NTP specification has 318 traditionally followed a pattern of employing common settings and 319 code even when not strictly necessary, which at times has resulted in 320 negative security and privacy implications (see e.g. 321 [I-D.ietf-ntp-data-minimization]). The use of the NTP well-known 322 port (123) for the srcport and dstport variables is not required for 323 all operating modes. Such unnecessary usage comes at the expense of 324 reducing the amount of work required for an attacker to successfully 325 perform off-path/blind attacks against NTP. Therefore, this document 326 formally updates [RFC5905], recommending the use of transport- 327 protocol port randomization when use of the NTP well-known port is 328 not required. 330 This issue has been tracked by US-CERT with VU#597821, and has been 331 assigned CVE-2019-11331. 333 8. Acknowledgments 335 The authors would like to thank (in alphabetical order) Ivan Arce, 336 Dhruv Dhody, Todd Glassey, Watson Ladd, Aanchal Malhotra, Danny 337 Mayer, Gary E. Miller, Tomoyuki Sahara, Dieter Sibold, Steven 338 Sommars, Kristof Teichel, and Ulrich Windl, for providing valuable 339 comments on earlier versions of this document. 341 Watson Ladd raised the problem of DDoS mitigation when the NTP well- 342 known port is employed as the client port (discussed in Section 3.3 343 of this document). 345 The authors would like to thank Harlan Stenn for answering questions 346 about nwtime.org's NTP implementation. 348 Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for 349 their love and support. 351 9. References 353 9.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 361 "Network Time Protocol Version 4: Protocol and Algorithms 362 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 363 . 365 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 366 Protocol Port Randomization", BCP 156, RFC 6056, 367 DOI 10.17487/RFC6056, January 2011, 368 . 370 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 371 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 372 May 2017, . 374 9.2. Informative References 376 [chrony] "chrony", . 378 [I-D.ietf-ntp-data-minimization] 379 Franke, D. and A. Malhotra, "NTP Client Data 380 Minimization", draft-ietf-ntp-data-minimization-04 (work 381 in progress), March 2019. 383 [I-D.irtf-pearg-numeric-ids-generation] 384 Gont, F. and I. Arce, "On the Generation of Transient 385 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 386 generation-03 (work in progress), September 2020. 388 [NIST-NTP] 389 Sherman, J. and J. Levine, "Usage Analysis of the NIST 390 Internet Time Service", Journal of Research of the 391 National Institute of Standards and Technology Volume 121, 392 March 2016, . 394 [NTP-CHLNG] 395 Sommars, S., "Challenges in Time Transfer Using the 396 Network Time Protocol (NTP)", Proceedings of the 48th 397 Annual Precise Time and Time Interval Systems and 398 Applications Meeting, Monterey, California pp. 271-290, 399 January 2017, . 402 [NTP-FRAG] 403 Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 404 "Attacking the Network Time Protocol", NDSS'17, San Diego, 405 CA. Feb 2017, 2017, 406 . 408 [NTP-security] 409 Malhotra, A., Van Gundy, M., Varia, V., Kennedy, H., 410 Gardner, J., and S. Goldberg, "The Security of NTP's 411 Datagram Protocol", Cryptology ePrint Archive Report 412 2016/1006, 2016, . 414 [NTP-VULN] 415 Network Time Foundation, "Security Notice", Network Time 416 Foundation's NTP Support Wiki , 417 . 419 [OpenNTPD] 420 "OpenNTPD Project", . 422 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 423 RFC 4953, DOI 10.17487/RFC4953, July 2007, 424 . 426 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 427 DOI 10.17487/RFC5927, July 2010, 428 . 430 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 431 Code: The Implementation Status Section", BCP 205, 432 RFC 7942, DOI 10.17487/RFC7942, July 2016, 433 . 435 Authors' Addresses 437 Fernando Gont 438 SI6 Networks 439 Evaristo Carriego 2644 440 Haedo, Provincia de Buenos Aires 1706 441 Argentina 443 Phone: +54 11 4650 8472 444 Email: fgont@si6networks.com 445 URI: https://www.si6networks.com 447 Guillermo Gont 448 SI6 Networks 449 Evaristo Carriego 2644 450 Haedo, Provincia de Buenos Aires 1706 451 Argentina 453 Phone: +54 11 4650 8472 454 Email: ggont@si6networks.com 455 URI: https://www.si6networks.com 457 Miroslav Lichvar 458 Red Hat 459 Purkynova 115 460 Brno 612 00 461 Czech Republic 463 Email: mlichvar@redhat.com