idnits 2.17.1 draft-ietf-ntp-port-randomization-07.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 405 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 (June 10, 2021) is 1051 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-07 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: December 12, 2021 Red Hat 7 June 10, 2021 9 Port Randomization in the Network Time Protocol Version 4 10 draft-ietf-ntp-port-randomization-07 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 facilitates 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 December 12, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 NAPT devices . . . . . . . . . . . . . . . . . 5 66 4. Update to RFC5905 . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The Network Time Protocol (NTP) is one of the oldest Internet 79 protocols, and currently specified in [RFC5905]. Since its original 80 implementation, standardization, and deployment, a number of 81 vulnerabilities have been found both in the NTP specification and in 82 some of its implementations [NTP-VULN]. Some of these 83 vulnerabilities allow for off-path/blind attacks, where an attacker 84 can send forged packets to one or both NTP peers for achieving Denial 85 of Service (DoS), time-shifts, or other undesirable outcomes. Many 86 of these attacks require the attacker to guess or know at least a 87 target NTP association, typically identified by the tuple {srcaddr, 88 srcport, dstaddr, dstport, keyid} (see section 9.1 of [RFC5905]). 89 Some of these parameters may be easily known or guessed. 91 NTP can operate in several modes. Some of these modes rely on the 92 ability of nodes to receive unsolicited packets, and therefore 93 require the use of the NTP well-known port (123). However, for modes 94 where the use of a well-known port is not required, employing the NTP 95 well-known port unnecessarily facilitates the ability of an attacker 96 to perform blind/off-path attacks (since knowledge of the port 97 numbers is typically required for such attacks). A recent study 98 [NIST-NTP] that analyzes the port numbers employed by NTP clients 99 suggests that a considerable number of NTP clients employ the NTP 100 well-known port as their local port, or select predictable ephemeral 101 port numbers, thus unnecessarily facilitating the ability of 102 attackers to perform blind/off-path attacks against NTP. 104 BCP 156 [RFC6056] already recommends the randomization of transport- 105 protocol ephemeral ports. This document aligns NTP with the 106 recommendation in BCP 156 [RFC6056], by formally updating [RFC5905] 107 such that port randomization is employed for those NTP modes for 108 which the use of the NTP well-known port is not needed. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. Considerations About Port Randomization in NTP 120 The following subsections analyze a number of considerations about 121 transport-protocol ephemeral port randomization when applied to NTP. 123 3.1. Mitigation Against Off-path Attacks 125 There has been a fair share of work in the area of off-path/blind 126 attacks against transport protocols and upper-layer protocols, such 127 as [RFC5927] and [RFC4953]. Whether the target of the attack is a 128 transport protocol instance (e.g., TCP connection) or an upper-layer 129 protocol instance (e.g., an application protocol instance), the 130 attacker is required to know or guess the five-tuple {Protocol, IP 131 Source Address, IP Destination Address, Source Port, Destination 132 Port} that identifies the target transport protocol instance or the 133 transport protocol instance employed by the target upper-layer 134 protocol instance. Therefore, increasing the difficulty of guessing 135 this five-tuple helps mitigate blind/off-path attacks. 137 As a result of these considerations, transport-protocol ephemeral 138 port randomization is a best current practice (BCP 156) that helps 139 mitigate off-path attacks at the transport-layer. This document 140 aligns the NTP specification [RFC5905] with the existing best current 141 practice on ephemeral port selection, irrespective of other 142 techniques that may (and should) be implemented for mitigating off- 143 path attacks. 145 We note that transport-protocol ephemeral port randomization is a 146 transport-layer mitigation against off-path/blind attacks, and does 147 not preclude (nor is it precluded by) other possible mitigations for 148 off-path attacks that might be implemented at other layers (e.g. 149 [I-D.ietf-ntp-data-minimization]). For instance, some of the 150 aforementioned mitigations may be ineffective against some off-path 151 attacks [NTP-FRAG] or may benefit from the additional entropy 152 provided by port randomization [NTP-security]. 154 3.2. Effects on Path Selection 156 Intermediate systems implementing the Equal-Cost Multi-Path (ECMP) 157 algorithm may select the outgoing link by computing a hash over a 158 number of values, that include the transport-protocol source port. 159 Thus, as discussed in [NTP-CHLNG], the selected client port may have 160 an influence on the measured offset and delay. 162 If the source port is changed with each request, packets in different 163 exchanges will be more likely to take different paths, which could 164 cause the measurements to be less stable and have a negative impact 165 on the stability of the clock. 167 Network paths to/from a given server are less likely to change 168 between requests if port randomization is applied on a per- 169 association basis. This approach minimizes the impact on the 170 stability of NTP measurements, but may cause different clients in the 171 same network synchronized to the same NTP server to have a 172 significant stable offset between their clocks due to their NTP 173 exchanges consistently taking different paths with different 174 asymmetry in the network delay. 176 Section 4 recommends NTP implementations to randomize the ephemeral 177 port number of client/server associations. The choice of whether to 178 randomize the port number on a per-association or a per-request basis 179 is left to the implementation. 181 3.3. Filtering of NTP traffic 183 In a number of scenarios (such as when mitigating DDoS attacks), a 184 network operator may want to differentiate between NTP requests sent 185 by clients, and NTP responses sent by NTP servers. If an 186 implementation employs the NTP well-known port for the client port 187 number, requests/responses cannot be readily differentiated by 188 inspecting the source and destination port numbers. Implementation 189 of port randomization for non-symmetrical modes allows for simple 190 differentiation of NTP requests and responses, and for the 191 enforcement of security policies that may be valuable for the 192 mitigation of DDoS attacks, when all NTP clients in a given network 193 employ port randomization. 195 3.4. Effect on NAPT devices 197 Some NAPT devices will reportedly not translate the source port of a 198 packet when a system port number (i.e., a port number in the range 199 0-1023) [RFC6335] is employed. In networks where such NAPT devices 200 are employed, use of the NTP well-known port for the client port may 201 limit the number of hosts that may successfully employ NTP client 202 implementations at any given time. 204 NOTES: 205 NAPT devices are defined in Section 4.1.2 of [RFC2663]. 207 The reported behavior is similar to the special treatment of UDP 208 port 500 that has been documented in Section 2.3 of [RFC3715]. 210 In the case of NAPT devices that will translate the source port even 211 when a system port is employed, packets reaching the external realm 212 of the NAPT will not employ the NTP well-known port as the source 213 port, as a result of the port translation function performed by the 214 NAPT device. 216 NOTE: 217 NAPT devices are defined in Section 4.1.2 of [RFC2663]. 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, to avoid revealing the randomized port to other 238 associations. 240 If a client implementation performs ephemeral port randomization 241 on a per-request basis, it SHOULD close the corresponding socket/ 242 port after each request/response exchange. In order to prevent 243 duplicate or delayed server packets from eliciting ICMP port 244 unreachable error messages at the client, the client MAY wait for 245 more responses from the server for a specific period of time (e.g. 246 3 seconds) before closing the UDP socket/port. 248 NOTES: 249 Randomizing the ephemeral port number on a per-request basis 250 will better mitigate off-path/blind attacks, particularly if 251 the socket/port is closed after each request/response exchange, 252 as recommended above. The choice of whether to randomize the 253 ephemeral port number on a per-request or a per-association 254 basis is left to the implementation, and should consider the 255 possible effects on path selection along with its possible 256 impact on time measurement. 258 On most current operating systems, which implement ephemeral 259 port randomization [RFC6056], an NTP client may normally rely 260 on the operating system to perform ephemeral port 261 randomization. For example, NTP implementations using POSIX 262 sockets may achieve ephemeral port randomization by *not* 263 binding the socket with the bind() function, or binding it to 264 port 0, which has a special meaning of "any port". connect()ing 265 the socket will make the port inaccessible by other systems 266 (that is, only packets from the specified remote socket will be 267 received by the application). 269 5. Implementation Status 271 [RFC Editor: Please remove this section before publication of this 272 document as an RFC.] 274 This section records the status of known implementations of the 275 protocol defined by this specification at the time of posting of this 276 Internet-Draft, and is based on a proposal described in [RFC7942]. 277 The description of implementations in this section is intended to 278 assist the IETF in its decision processes in progressing drafts to 279 RFCs. Please note that the listing of any individual implementation 280 here does not imply endorsement by the IETF. Furthermore, no effort 281 has been spent to verify the information presented here that was 282 supplied by IETF contributors. This is not intended as, and must not 283 be construed to be, a catalog of available implementations or their 284 features. Readers are advised to note that other implementations may 285 exist. 287 OpenNTPD: 288 [OpenNTPD] has never explicitly set the local port of NTP clients, 289 and thus employs the ephemeral port selection algorithm 290 implemented by the operating system. Thus, on all operating 291 systems that implement port randomization (such as current 292 versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ 293 port randomization for client ports. 295 chrony: 296 [chrony] by default does not set the local client port, and thus 297 employs the ephemeral port selection algorithm implemented by the 298 operating system. Thus, on all operating systems that implement 299 port randomization (such as current versions of OpenBSD, Linux, 300 and FreeBSD), chrony will employ port randomization for client 301 ports. 303 nwtime.org's sntp client: 304 sntp does not explicitly set the local port, and thus employs the 305 ephemeral port selection algorithm implemented by the operating 306 system. Thus, on all operating systems that implement port 307 randomization (such as current versions of OpenBSD, Linux, and 308 FreeBSD), it will employ port randomization for client ports. 310 6. IANA Considerations 312 There are no IANA registries within this document. The RFC-Editor 313 can remove this section before publication of this document as an 314 RFC. 316 7. Security Considerations 318 The security implications of predictable numeric identifiers 319 [I-D.irtf-pearg-numeric-ids-generation] (and of predictable 320 transport-protocol port numbers [RFC6056] in particular) have been 321 known for a long time now. However, the NTP specification has 322 traditionally followed a pattern of employing common settings even 323 when not strictly necessary, which at times has resulted in negative 324 security and privacy implications (see e.g. 325 [I-D.ietf-ntp-data-minimization]). The use of the NTP well-known 326 port (123) for the srcport and dstport variables is not required for 327 all operating modes. Such unnecessary usage comes at the expense of 328 reducing the amount of work required for an attacker to successfully 329 perform off-path/blind attacks against NTP. Therefore, this document 330 formally updates [RFC5905], recommending the use of transport- 331 protocol port randomization when use of the NTP well-known port is 332 not required. 334 This issue has been assigned CVE-2019-11331 [VULN-REPORT] in the U.S. 335 National Vulnerability Database (NVD). 337 8. Acknowledgments 339 The authors would like to thank (in alphabetical order) Ivan Arce, 340 Roman Danyliw, Dhruv Dhody, Lars Eggert, Todd Glassey, Blake Hudson, 341 Benjamin Kaduk, Erik Kline, Watson Ladd, Aanchal Malhotra, Danny 342 Mayer, Gary E. Miller, Bjorn Mork, Hal Murray, Francesca Palombini, 343 Tomoyuki Sahara, Zaheduzzaman Sarker, Dieter Sibold, Steven Sommars, 344 Jean St-Laurent, Kristof Teichel, Brian Trammell, Eric Vyncke, Ulrich 345 Windl, and Dan Wing, for providing valuable comments on earlier 346 versions of this document. 348 Watson Ladd raised the problem of DDoS mitigation when the NTP well- 349 known port is employed as the client port (discussed in Section 3.3 350 of this document). 352 The authors would like to thank Harlan Stenn for answering questions 353 about nwtime.org's NTP implementation. 355 Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for 356 their love and support. 358 9. References 360 9.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 368 "Network Time Protocol Version 4: Protocol and Algorithms 369 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 370 . 372 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 373 Protocol Port Randomization", BCP 156, RFC 6056, 374 DOI 10.17487/RFC6056, January 2011, 375 . 377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 379 May 2017, . 381 9.2. Informative References 383 [chrony] "chrony", . 385 [I-D.ietf-ntp-data-minimization] 386 Franke, D. F. and A. Malhotra, "NTP Client Data 387 Minimization", draft-ietf-ntp-data-minimization-04 (work 388 in progress), March 2019. 390 [I-D.irtf-pearg-numeric-ids-generation] 391 Gont, F. and I. Arce, "On the Generation of Transient 392 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 393 generation-07 (work in progress), February 2021. 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 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 430 Translator (NAT) Terminology and Considerations", 431 RFC 2663, DOI 10.17487/RFC2663, August 1999, 432 . 434 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 435 (NAT) Compatibility Requirements", RFC 3715, 436 DOI 10.17487/RFC3715, March 2004, 437 . 439 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 440 RFC 4953, DOI 10.17487/RFC4953, July 2007, 441 . 443 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 444 DOI 10.17487/RFC5927, July 2010, 445 . 447 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 448 Cheshire, "Internet Assigned Numbers Authority (IANA) 449 Procedures for the Management of the Service Name and 450 Transport Protocol Port Number Registry", BCP 165, 451 RFC 6335, DOI 10.17487/RFC6335, August 2011, 452 . 454 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 455 Code: The Implementation Status Section", BCP 205, 456 RFC 7942, DOI 10.17487/RFC7942, July 2016, 457 . 459 [VULN-REPORT] 460 The MITRE Corporation, "CVE-2019-11331", April 2019, 461 . 464 Authors' Addresses 466 Fernando Gont 467 SI6 Networks 468 Evaristo Carriego 2644 469 Haedo, Provincia de Buenos Aires 1706 470 Argentina 472 Phone: +54 11 4650 8472 473 Email: fgont@si6networks.com 474 URI: https://www.si6networks.com 475 Guillermo Gont 476 SI6 Networks 477 Evaristo Carriego 2644 478 Haedo, Provincia de Buenos Aires 1706 479 Argentina 481 Phone: +54 11 4650 8472 482 Email: ggont@si6networks.com 483 URI: https://www.si6networks.com 485 Miroslav Lichvar 486 Red Hat 487 Purkynova 115 488 Brno 612 00 489 Czech Republic 491 Email: mlichvar@redhat.com