idnits 2.17.1 draft-ietf-ntp-port-randomization-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 '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 389 has weird spacing: '...ifornia pp. 2...' -- The document date (July 26, 2020) is 1363 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-02 Summary: 0 errors (**), 0 flaws (~~), 4 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: January 27, 2021 Red Hat 7 July 26, 2020 9 Port Randomization in the Network Time Protocol Version 4 10 draft-ietf-ntp-port-randomization-05 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 January 27, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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. 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 . . . . . . . . . . . . . . . . . 8 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}. Some of these parameters may be 89 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 a service/well-known port number (123). However, 94 for modes where the use of a service/well-known port is not required, 95 employing the well-known/service port improves the ability of an 96 attacker to perform blind/off-path attacks (since knowledge of the 97 port 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 service/well-known port as their local port, or select predictable 101 ephemeral port numbers, thus improving the ability of attackers to 102 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 service port is not needed. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Considerations About Port Randomization in NTP 118 The following subsections analyze a number of considerations about 119 transport-protocol port randomization when applied to NTP. 121 3.1. Mitigation Against Off-path Attacks 123 There has been a fair share of work in the area of off-path/blind 124 attacks against transport protocols and upper-layer protocols, such 125 as [RFC5927] and [RFC4953]. Whether the target of the attack is a 126 transport protocol instance (e.g., TCP connection) or an upper-layer 127 protocol instance (e.g., an application protocol instance), the 128 attacker is required to know or guess the five-tuple {Protocol, IP 129 Source Address, IP Destination Address, Source Port, Destination 130 Port} that identifies the target transport protocol instance or the 131 transport protocol instance employed by the target upper-layer 132 protocol instance. Therefore, increasing the difficulty of guessing 133 this five-tuple helps mitigate blind/off-path attacks. 135 As a result of this considerations, BCP 156 [RFC6056] recommends the 136 randomization of transport-protocol ephemeral ports. Thus, this 137 document aims to bring the NTP specification [RFC5905] in line with 138 the aforementioned recommendation. 140 We note that the use of port randomization is a transport-layer 141 mitigation against off-path/blind attacks, and does not preclude (nor 142 is it precluded by) other possible mitigations for off-path attacks 143 that might be implemented by an application protocol (e.g. 144 [I-D.ietf-ntp-data-minimization]). For instance, some of the 145 aforementioned mitigations may be ineffective against some off-path 146 attacks [NTP-FRAG] or may benefit from the additional entropy 147 provided by port randomization [NTP-security]. 149 3.2. Effects on Path Selection 151 Intermediate systems implementing the Equal-Cost Multi-Path (ECMP) 152 algorithm may select the outgoing link by computing a hash over a 153 number of values, that include the transport-protocol source port. 154 Thus, as discussed in [NTP-CHLNG], the selected client port may have 155 an influence on the measured offset and delay. 157 If the source port is changed with each request, packets in different 158 exchanges will be more likely to take different paths, which could 159 cause the measurements to be less stable and have a negative impact 160 on the stability of the clock. 162 Network paths to/from a given server are less likely to change 163 between requests if port randomization is applied on a per- 164 association basis. This approach minimizes the impact on the 165 stability of NTP measurements, but may cause different clients in the 166 same network synchronized to the same NTP server to have a 167 significant stable offset between their clocks due to their NTP 168 exchanges consistently taking different paths with different 169 asymmetry in the network delay. 171 Section 4 recommends NTP implementations to randomize the ephemeral 172 port number of client/server associations. The choice of whether to 173 randomize the port number on a per-association or a per-request basis 174 is left to the implementation. 176 3.3. Filtering of NTP traffic 178 In a number of scenarios (such as when mitigating DDoS attacks), a 179 network operator may want to differentiate between NTP requests sent 180 by clients, and NTP responses sent by NTP servers. If an 181 implementation employs the NTP service port for the client port 182 number, requests/responses cannot be readily differentiated by 183 inspecting the source and destination port numbers. Implementation 184 of port randomization for non-symmetrical modes allows for simple 185 differentiation of NTP requests and responses, and for the 186 enforcement of security policies that may be valuable for the 187 mitigation of DDoS attacks, when all NTP clients in a given network 188 employ port randomization. 190 3.4. Effect on NAT devices 192 Some NAT devices will not translate the source port of a packet when 193 a privileged port number is employed. In networks where such NAT 194 devices are employed, use of the NTP service port for the client port 195 will essentially limit the number of hosts that may successfully 196 employ NTP client implementations. 198 In the case of NAT devices that will translate the source port even 199 when a privileged port is employed, packets reaching the external 200 realm of the NAT will not employ the NTP service port as the local 201 port, since the local port will normally be translated by the NAT 202 device possibly, but not necessarily, with a random port. 204 3.5. Relation to Other Mitigations for Off-Path Attacks 206 Ephemeral Port Randomization is a best current practice (BCP 156) 207 that helps mitigate off-path attacks at the transport-layer. It is 208 orthogonal to other possible mitigations for off-path attacks that 209 may be implemented at other layers (such as the use of timestamps in 210 NTP) which may or may not be effective against some off-path attacks 211 (see e.g. [NTP-FRAG]. This document aligns NTP with the existing 212 best current practice on ephemeral port selection, irrespective of 213 other techniques that may (and should) be implemented for mitigating 214 off-path attacks. 216 4. Update to RFC5905 218 The following text from Section 9.1 ("Peer Process Variables") of 219 [RFC5905]: 221 dstport: UDP port number of the client, ordinarily the NTP port 222 number PORT (123) assigned by the IANA. This becomes the source 223 port number in packets sent from this association. 225 is replaced with: 227 dstport: UDP port number of the client. In the case of broadcast 228 server mode (5) and symmetric modes (1 and 2), it SHOULD contain 229 the NTP port number PORT (123) assigned by the IANA. In the 230 client mode (3), it SHOULD contain a randomized port number, as 231 specified in [RFC6056]. The value in this variable becomes the 232 source port number of packets sent from this association. The 233 randomized port number SHOULD NOT be shared with other 234 associations. 236 If a client implementation performs port randomization on a per- 237 request basis, it SHOULD close the corresponding socket/port after 238 each request/response exchange. In order to prevent duplicate or 239 delayed server packets from eliciting ICMP port unreachable error 240 messages at the client, the client MAY wait for more responses 241 from the server for a specific period of time (e.g. 3 seconds) 242 before closing the UDP socket/port. 244 NOTES: 245 The choice of whether to randomize the port number on a per- 246 request or a per-association basis is left to the 247 implementation, and should consider, among others, the 248 considerations discussed in Section 3.2. 250 On most current operating systems, which implement ephemeral 251 port randomization [RFC6056], an NTP client may normally rely 252 on the operating system to perform port randomization. For 253 example, NTP implementations using POSIX sockets may achieve 254 port randomization by *not* binding the socket with the bind() 255 function, or binding it to port 0, which has a special meaning 256 of "any port". connect()ing the socket will make the port 257 inaccessible by other systems (that is, only packets from the 258 specified remote socket will be received by the application). 260 5. Implementation Status 262 [RFC Editor: Please remove this section before publication of this 263 document as an RFC.] 265 This section records the status of known implementations of the 266 protocol defined by this specification at the time of posting of this 267 Internet-Draft, and is based on a proposal described in [RFC7942]. 268 The description of implementations in this section is intended to 269 assist the IETF in its decision processes in progressing drafts to 270 RFCs. Please note that the listing of any individual implementation 271 here does not imply endorsement by the IETF. Furthermore, no effort 272 has been spent to verify the information presented here that was 273 supplied by IETF contributors. This is not intended as, and must not 274 be construed to be, a catalog of available implementations or their 275 features. Readers are advised to note that other implementations may 276 exist. 278 OpenNTPD: 279 [OpenNTPD] has never explicitly set the local port of NTP clients, 280 and thus employs the ephemeral port selection algorithm 281 implemented by the operating system. Thus, on all operating 282 systems that implement port randomization (such as current 283 versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ 284 port randomization for client ports. 286 chrony: 287 [chrony] by default does not set the local client port, and thus 288 employs the ephemeral port selection algorithm implemented by the 289 operating system. Thus, on all operating systems that implement 290 port randomization (such as current versions of OpenBSD, Linux, 291 and FreeBSD), chrony will employ port randomization for client 292 ports. 294 nwtime.org's sntp client: 295 sntp does not explicitly set the local port, and thus employs the 296 ephemeral port selection algorithm implemented by the operating 297 system. Thus, on all operating systems that implement port 298 randomization (such as current versions of OpenBSD, Linux, and 299 FreeBSD), it will employ port randomization for client ports. 301 6. IANA Considerations 303 There are no IANA registries within this document. The RFC-Editor 304 can remove this section before publication of this document as an 305 RFC. 307 7. Security Considerations 309 The security implications of predictable numeric identifiers 310 [I-D.irtf-pearg-numeric-ids-generation] (and of predictable 311 transport-protocol port numbers [RFC6056] in particular) have been 312 known for a long time now. However, the NTP specification has 313 traditionally followed a pattern of employing common settings and 314 code even when not strictly necessary, which at times has resulted in 315 negative security and privacy implications (see e.g. 316 [I-D.ietf-ntp-data-minimization]). The use of the NTP service port 317 (123) for the srcport and dstport variables is not required for all 318 operating modes, and such unnecessary usage comes at the expense of 319 reducing the amount of work required for an attacker to successfully 320 perform off-path/blind attacks against NTP. Therefore, this document 321 formally updates [RFC5905], recommending the use of transport- 322 protocol port randomization when use of the NTP service port is not 323 required. 325 This issue has been tracked by US-CERT with VU#597821, and has been 326 assigned CVE-2019-11331. 328 8. Acknowledgments 330 The authors would like to thank (in alphabetical order) Ivan Arce, 331 Todd Glassey, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E. 332 Miller, Tomoyuki Sahara, Dieter Sibold, Steven Sommars, and Ulrich 333 Windl, for providing valuable comments on earlier versions of this 334 document. 336 Watson Ladd raised the problem of DDoS mitigation when the NTP 337 service port is employed as the client port (discussed in Section 3.3 338 of this document). 340 The authors would like to thank Harlan Stenn for answering questions 341 about nwtime.org's NTP implementation. 343 Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for 344 their love and support. 346 9. References 348 9.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 356 "Network Time Protocol Version 4: Protocol and Algorithms 357 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 358 . 360 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 361 Protocol Port Randomization", BCP 156, RFC 6056, 362 DOI 10.17487/RFC6056, January 2011, 363 . 365 9.2. Informative References 367 [chrony] "chrony", . 369 [I-D.ietf-ntp-data-minimization] 370 Franke, D. and A. Malhotra, "NTP Client Data 371 Minimization", draft-ietf-ntp-data-minimization-04 (work 372 in progress), March 2019. 374 [I-D.irtf-pearg-numeric-ids-generation] 375 Gont, F. and I. Arce, "On the Generation of Transient 376 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 377 generation-02 (work in progress), May 2020. 379 [NIST-NTP] 380 Sherman, J. and J. Levine, "Usage Analysis of the NIST 381 Internet Time Service", Journal of Research of the 382 National Institute of Standards and Technology Volume 121, 383 March 2016, . 385 [NTP-CHLNG] 386 Sommars, S., "Challenges in Time Transfer Using the 387 Network Time Protocol (NTP)", Proceedings of the 48th 388 Annual Precise Time and Time Interval Systems and 389 Applications Meeting, Monterey, California pp. 271-290, 390 January 2017, . 393 [NTP-FRAG] 394 Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 395 "Attacking the Network Time Protocol", NDSS'17, San Diego, 396 CA. Feb 2017, 2017, 397 . 399 [NTP-security] 400 Malhotra, A., Van Gundy, M., Varia, V., Kennedy, H., 401 Gardner, J., and S. Goldberg, "The Security of NTP's 402 Datagram Protocol", Cryptology ePrint Archive Report 403 2016/1006, 2016, . 405 [NTP-VULN] 406 Network Time Foundation, "Security Notice", Network Time 407 Foundation's NTP Support Wiki , 408 . 410 [OpenNTPD] 411 "OpenNTPD Project", . 413 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 414 RFC 4953, DOI 10.17487/RFC4953, July 2007, 415 . 417 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 418 DOI 10.17487/RFC5927, July 2010, 419 . 421 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 422 Code: The Implementation Status Section", BCP 205, 423 RFC 7942, DOI 10.17487/RFC7942, July 2016, 424 . 426 Authors' Addresses 428 Fernando Gont 429 SI6 Networks 430 Evaristo Carriego 2644 431 Haedo, Provincia de Buenos Aires 1706 432 Argentina 434 Phone: +54 11 4650 8472 435 Email: fgont@si6networks.com 436 URI: https://www.si6networks.com 438 Guillermo Gont 439 SI6 Networks 440 Evaristo Carriego 2644 441 Haedo, Provincia de Buenos Aires 1706 442 Argentina 444 Phone: +54 11 4650 8472 445 Email: ggont@si6networks.com 446 URI: https://www.si6networks.com 448 Miroslav Lichvar 449 Red Hat 450 Purkynova 115 451 Brno 612 00 452 Czech Republic 454 Email: mlichvar@redhat.com