idnits 2.17.1 draft-gont-ntp-port-randomization-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted 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 -- The document date (May 20, 2019) is 1803 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 (~~), 2 warnings (==), 3 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 Obsoletes: rfc5905 (if approved) SI6 Networks 5 Intended status: Standards Track May 20, 2019 6 Expires: November 21, 2019 8 Port Randomization in the Network Time Protocol Version 4 9 draft-gont-ntp-port-randomization-01 11 Abstract 13 The Network Time Protocol can operate in several modes. Some of 14 these modes are based on the receipt of unsolicited packets, and 15 therefore require the use of a service/well-known port as the local 16 port number. However, in the case of NTP modes where the use of a 17 service/well-known port is not required, employing such well-known/ 18 service port unnecessarily increases the ability of attackers to 19 perform blind/off-path attacks, since knowledge of such port number 20 is typically required for such attacks. This document formally 21 updates RFC5905, recommending the use of port randomization for those 22 modes 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 November 21, 2019. 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 This document may not be modified, and derivative works of it may not 57 be created, and it may not be published except as an Internet-Draft. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Update to RFC5905 . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 The Network Time Protocol (NTP) is one of the oldest Internet 76 protocols, and currently specified in [RFC5905]. Since its its 77 original implementation, standardization and deployment, a number of 78 vulnerabilities have been found both in the NTP specification and in 79 some of its implementations [NTP-VULN]. Some of these 80 vulnerabilities allow for off-path/blind attacks, where an attacker 81 can send forged packets to one or both NTP peers for achieving Denial 82 of Service (DoS), time-shifts, and other undesirable outcomes. Many 83 of these attacks require the attacker to guess or know at least a 84 target association, typically identified by the tuple {srcaddr, 85 srcport, dstaddr, dstport, keyid}. Some of these parameters may be 86 easily known or guessed. 88 NTP can operate in several modes. Some of these modes rely on the 89 ability to receive unsolicited packets, and therefore require the use 90 of a service/well-known port number. However, for modes where the 91 use of a service/well-known port is not required, employing such 92 well-known/service port improves the ability of an attacker to 93 perform blind/off-path attacks (since knowledge of such port number 94 is typically required for such attacks). A recent study [NIST-NTP] 95 that analyzes the port numbers employed by NTP peers suggests that a 96 considerable number of NTP peers employ the NTP service/well-known 97 port as their local port, or select predictable ephemeral port 98 numbers, thus improving the ability of attackers to perform blind/ 99 off-path attacks against NTP. 101 This document formally updates [RFC5905], recommending the use of 102 port randomization for those NTP modes where use of the NTP service 103 port is not required. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Update to RFC5905 113 The specification of the "srcport" and "dstport" peer process 114 variables from Section 9.1 ("Peer Process Variables") of [RFC5905] is 115 updated as follows: 117 srcport: UDP port number of the server or reference clock. This 118 becomes the destination port number in packets sent from this 119 association. When operating in symmetric modes (1 and 2), this field 120 must contain the NTP port number PORT (123) assigned by the IANA. In 121 other modes, it SHOULD contain a randomized port number, as specified 122 in [RFC6056]. 124 dstport: UDP port number of the client. In the case of broadcast 125 server mode (5) and symmetric modes (1 and 2), it must contain the 126 NTP port number PORT (123) assigned by the IANA. In other cases, it 127 SHOULD contain a randomized port number, as specified in [RFC6056]. 128 The value in this variable becomes the source port number in packets 129 sent from this association. 131 NOTES: 132 The port number is to be randomized on a per-association basis. 133 That is, a random port number is selected when an association is 134 first mobilized, and the selected port number is expected to 135 remain constant during the life of an association. 137 On most current operating systems (that implement ephemeral port 138 randomization [RFC6056]), an NTP peer may normally rely on the 139 operating system for performing port randomization. For example, 140 NTP implementations employing the Sockets API may achieve port 141 randomization by *not* specifying the local port for the 142 corresponding socket, or bind()ing the local socket to the 143 "special" port 0 (which for the Sockets API has the special 144 meaning of "any port"). 146 4. Implementation Status 148 [RFC Editor: Please remove this section before publication of this 149 document as an RFC.] 151 This section records the status of known implementations of the 152 protocol defined by this specification at the time of posting of this 153 Internet-Draft, and is based on a proposal described in [RFC7942]. 154 The description of implementations in this section is intended to 155 assist the IETF in its decision processes in progressing drafts to 156 RFCs. Please note that the listing of any individual implementation 157 here does not imply endorsement by the IETF. Furthermore, no effort 158 has been spent to verify the information presented here that was 159 supplied by IETF contributors. This is not intended as, and must not 160 be construed to be, a catalog of available implementations or their 161 features. Readers are advised to note that other implementations may 162 exist. 164 OpenNTPD: 165 [OpenNTPD] has never explictly set the local port of NTP clients, 166 and thus employs the ephemeral port selection algorithm 167 implemented by the operating system. Thus, on all operating 168 systems that implement port randomization (such as current 169 versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ 170 port randomization for client ports. 172 chrony: 173 [chrony] has never explictly set the local port of NTP clients, 174 and thus employs the ephemeral port selection algorithm 175 implemented by the operating system. Thus, on all operating 176 systems that implement port randomization (such as current 177 versions of OpenBSD, Linux, and FreeBSD), chrony will employ port 178 randomization for client ports. 180 nwtime.org's sntp client: 181 sntp does not explictly set the local port, and thus employs the 182 ephemeral port selection algorithm implemented by the operating 183 system. Thus, on all operating systems that implement port 184 randomization (such as current versions of OpenBSD, Linux, and 185 FreeBSD), it will employ port randomization for client ports. 187 5. IANA Considerations 189 There are no IANA registries within this document. The RFC-Editor 190 can remove this section before publication of this document as an 191 RFC. 193 6. Security Considerations 195 The security implications of predictable numeric identifiers 196 [I-D.gont-predictable-numeric-ids] (and of predictable transport- 197 protocol port numbers [RFC6056] in particular) have been known for a 198 long time now. However, the NTP specification have traditionally 199 followed a pattern of employing common settings and code even when 200 not strictly necessary, which at times has resulted in negative 201 security and privacy implications (see e.g. 202 [I-D.ietf-ntp-data-minimization]). The use of the NTP service port 203 (123) for the srcport and dstport variables is not required for all 204 operating modes, and such unnecessary usage comes at the expense of 205 reducing the amount of work required for an attacker to successfully 206 perform off-path/blind attacks against NTP. Therefore, this document 207 formally updates [RFC5905], recommending the use of transport- 208 protocol port randomization when use of the NTP service port is not 209 required. 211 This issue has been tracked by US-CERT with VU#597821, and has been 212 assigned CVE-2019-11331. 214 7. Acknowledgments 216 The authors would like to thank (in alphabetical order) Miroslav 217 Lichvar, and Steven Sommars, for providing valuable comments on 218 earlier versions of this document. 220 The authors would like to thank Harlan Stenn for answering questions 221 about nwtime.org's NTP implementation. 223 Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for 224 their love and support. 226 8. References 228 8.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 236 "Network Time Protocol Version 4: Protocol and Algorithms 237 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 238 . 240 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 241 Protocol Port Randomization", BCP 156, RFC 6056, 242 DOI 10.17487/RFC6056, January 2011, 243 . 245 8.2. Informative References 247 [chrony] "chrony", . 249 [I-D.gont-predictable-numeric-ids] 250 Gont, F. and I. Arce, "Security and Privacy Implications 251 of Numeric Identifiers Employed in Network Protocols", 252 draft-gont-predictable-numeric-ids-03 (work in progress), 253 March 2019. 255 [I-D.ietf-ntp-data-minimization] 256 Franke, D. and A. Malhotra, "NTP Client Data 257 Minimization", draft-ietf-ntp-data-minimization-04 (work 258 in progress), March 2019. 260 [NIST-NTP] 261 Sherman, J. and J. Levine, "Usage Analysis of the NIST 262 Internet Time Service", Journal of Research of the 263 National Institute of Standards and Technology Volume 121, 264 March 2016, . 266 [NTP-VULN] 267 Network Time Foundation, "Security Notice", Network Time 268 Foundation's NTP Support Wiki , 269 . 271 [OpenNTPD] 272 "OpenNTPD Project", . 274 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 275 Code: The Implementation Status Section", BCP 205, 276 RFC 7942, DOI 10.17487/RFC7942, July 2016, 277 . 279 Authors' Addresses 280 Fernando Gont 281 SI6 Networks 282 Evaristo Carriego 2644 283 Haedo, Provincia de Buenos Aires 1706 284 Argentina 286 Phone: +54 11 4650 8472 287 Email: fgont@si6networks.com 288 URI: https://www.si6networks.com 290 Guillermo Gont 291 SI6 Networks 292 Evaristo Carriego 2644 293 Haedo, Provincia de Buenos Aires 1706 294 Argentina 296 Phone: +54 11 4650 8472 297 Email: ggont@si6networks.com 298 URI: https://www.si6networks.com