idnits 2.17.1 draft-ietf-ntp-port-randomization-01.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 388 has weird spacing: '...ifornia pp. 2...' -- The document date (March 9, 2020) is 1503 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: September 10, 2020 Red Hat 7 March 9, 2020 9 Port Randomization in the Network Time Protocol Version 4 10 draft-ietf-ntp-port-randomization-01 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 September 10, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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, and 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. However, for 94 modes where the use of a service/well-known port is not required, 95 employing such well-known/service port improves the ability of an 96 attacker to perform blind/off-path attacks (since knowledge of such 97 port number 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 required. 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. And as such, 137 this document aims to bring the NTP specification [RFC5905] in line 138 with 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 delay and jitter values. 157 This might mean, for example, that two clients in the same network 158 synchronized with the same NTP server using a stable source port 159 (selected randomly or not) have a significant offset between their 160 clocks due to their NTP exchanges taking paths with different 161 asymmetry in the network delay. 163 If the clients changed their source port with each request, packets 164 in different exchanges would take different paths. The measured 165 delay and offset would be less stable, but the offset between the 166 clients' clocks would be smaller. The impact on stability of the 167 clocks would be mitigated by the clock filter algorithm, which 168 prefers samples with shorter delay. 170 On the other hand, if port-randomization is applied on a per- 171 association basis, request/responses to the same association would 172 likely follow the same path, since the IP addresses and transport 173 port numbers employed for an association would not change. This 174 would thus result in more stability of the measurements. 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-request"), since this is believed to be the 179 more conservative approach. However, implementations may override 180 this setting and perform port-randomization on a per-request basis. 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 SHOULD contain 234 the NTP port number PORT (123) assigned by the IANA. In other 235 cases, 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: 240 When port randomization is employed, the port number SHOULD be 241 randomized on a per-association basis. That is, a random port 242 number SHOULD selected when an association is first mobilized, 243 and the selected port number is expected to remain constant 244 during the life of an association. An implementation MAY, 245 however, override this setting and employ port randomization on 246 a per-request basis. 248 On most current operating systems, which implement ephemeral 249 port randomization [RFC6056], an NTP client may normally rely 250 on the operating system to perform port randomization. For 251 example, NTP implementations using POSIX sockets may achieve 252 port randomization by *not* binding the socket with the bind() 253 function, or binding it to port 0, which has a special meaning 254 of "any port". connect()ing the docket will make the port 255 inaccessible by other systems (that is, only packets from the 256 specified remote socket will be received by the application). 258 5. Implementation Status 260 [RFC Editor: Please remove this section before publication of this 261 document as an RFC.] 263 This section records the status of known implementations of the 264 protocol defined by this specification at the time of posting of this 265 Internet-Draft, and is based on a proposal described in [RFC7942]. 266 The description of implementations in this section is intended to 267 assist the IETF in its decision processes in progressing drafts to 268 RFCs. Please note that the listing of any individual implementation 269 here does not imply endorsement by the IETF. Furthermore, no effort 270 has been spent to verify the information presented here that was 271 supplied by IETF contributors. This is not intended as, and must not 272 be construed to be, a catalog of available implementations or their 273 features. Readers are advised to note that other implementations may 274 exist. 276 OpenNTPD: 277 [OpenNTPD] has never explicitly set the local port of NTP clients, 278 and thus employs the ephemeral port selection algorithm 279 implemented by the operating system. Thus, on all operating 280 systems that implement port randomization (such as current 281 versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ 282 port randomization for client ports. 284 chrony: 285 [chrony] by default does not set the local client port, and thus 286 employs the ephemeral port selection algorithm implemented by the 287 operating system. Thus, on all operating systems that implement 288 port randomization (such as current versions of OpenBSD, Linux, 289 and FreeBSD), chrony will employ port randomization for client 290 ports. 292 nwtime.org's sntp client: 293 sntp does not explicitly set the local port, and thus employs the 294 ephemeral port selection algorithm implemented by the operating 295 system. Thus, on all operating systems that implement port 296 randomization (such as current versions of OpenBSD, Linux, and 297 FreeBSD), it will employ port randomization for client ports. 299 6. IANA Considerations 301 There are no IANA registries within this document. The RFC-Editor 302 can remove this section before publication of this document as an 303 RFC. 305 7. Security Considerations 307 The security implications of predictable numeric identifiers 308 [I-D.gont-predictable-numeric-ids] (and of predictable transport- 309 protocol port numbers [RFC6056] in particular) have been known for a 310 long time now. However, the NTP specification has traditionally 311 followed a pattern of employing common settings and code even when 312 not strictly necessary, which at times has resulted in negative 313 security and privacy implications (see e.g. 314 [I-D.ietf-ntp-data-minimization]). The use of the NTP service port 315 (123) for the srcport and dstport variables is not required for all 316 operating modes, and such unnecessary usage comes at the expense of 317 reducing the amount of work required for an attacker to successfully 318 perform off-path/blind attacks against NTP. Therefore, this document 319 formally updates [RFC5905], recommending the use of transport- 320 protocol port randomization when use of the NTP service port is not 321 required. 323 This issue has been tracked by US-CERT with VU#597821, and has been 324 assigned CVE-2019-11331. 326 8. Acknowledgments 328 Watson Ladd raised the problem of DDoS mitigation when the NTP 329 service port is employed as the client port (discussed in Section 3.3 330 of this document). 332 The authors would like to thank (in alphabetical order) Ivan Arce, 333 Todd Glassey, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E. 335 Miller, Dieter Sibold, Steven Sommars, and Ulrich Windl, for 336 providing valuable comments on earlier versions of this document. 338 The authors would like to thank Harlan Stenn for answering questions 339 about nwtime.org's NTP implementation. 341 Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for 342 their love and support. 344 9. References 346 9.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 354 "Network Time Protocol Version 4: Protocol and Algorithms 355 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 356 . 358 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 359 Protocol Port Randomization", BCP 156, RFC 6056, 360 DOI 10.17487/RFC6056, January 2011, 361 . 363 9.2. Informative References 365 [chrony] "chrony", . 367 [I-D.gont-predictable-numeric-ids] 368 Gont, F. and I. Arce, "Security and Privacy Implications 369 of Numeric Identifiers Employed in Network Protocols", 370 draft-gont-predictable-numeric-ids-03 (work in progress), 371 March 2019. 373 [I-D.ietf-ntp-data-minimization] 374 Franke, D. and A. Malhotra, "NTP Client Data 375 Minimization", draft-ietf-ntp-data-minimization-04 (work 376 in progress), March 2019. 378 [NIST-NTP] 379 Sherman, J. and J. Levine, "Usage Analysis of the NIST 380 Internet Time Service", Journal of Research of the 381 National Institute of Standards and Technology Volume 121, 382 March 2016, . 384 [NTP-CHLNG] 385 Sommars, S., "Challenges in Time Transfer Using the 386 Network Time Protocol (NTP)", Proceedings of the 48th 387 Annual Precise Time and Time Interval Systems and 388 Applications Meeting, Monterey, California pp. 271-290, 389 January 2017, . 392 [NTP-FRAG] 393 Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 394 "Attacking the Network Time Protocol", NDSS'17, San Diego, 395 CA. Feb 2017, 2017, 396 . 398 [NTP-security] 399 Malhotra, A., Van Gundy, M., Varia, V., Kennedy, H., 400 Gardner, J., and S. Goldberg, "The Security of NTP's 401 Datagram Protocol", Cryptology ePrint Archive Report 402 2016/1006, 2016, . 404 [NTP-VULN] 405 Network Time Foundation, "Security Notice", Network Time 406 Foundation's NTP Support Wiki , 407 . 409 [OpenNTPD] 410 "OpenNTPD Project", . 412 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 413 RFC 4953, DOI 10.17487/RFC4953, July 2007, 414 . 416 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 417 DOI 10.17487/RFC5927, July 2010, 418 . 420 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 421 Code: The Implementation Status Section", BCP 205, 422 RFC 7942, DOI 10.17487/RFC7942, July 2016, 423 . 425 Authors' Addresses 426 Fernando Gont 427 SI6 Networks 428 Evaristo Carriego 2644 429 Haedo, Provincia de Buenos Aires 1706 430 Argentina 432 Phone: +54 11 4650 8472 433 Email: fgont@si6networks.com 434 URI: https://www.si6networks.com 436 Guillermo Gont 437 SI6 Networks 438 Evaristo Carriego 2644 439 Haedo, Provincia de Buenos Aires 1706 440 Argentina 442 Phone: +54 11 4650 8472 443 Email: ggont@si6networks.com 444 URI: https://www.si6networks.com 446 Miroslav Lichvar 447 Red Hat 448 Purkynova 115 449 Brno 612 00 450 Czech Republic 452 Email: mlichvar@redhat.com