idnits 2.17.1 draft-gont-numeric-ids-sec-considerations-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC3552, updated by this document, for RFC5378 checks: 2002-08-09) -- 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 (July 8, 2019) is 1751 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-gont-numeric-ids-generation-03 == Outdated reference: A later version (-05) exists of draft-gont-numeric-ids-history-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Gont 3 Internet-Draft SI6 Networks 4 Updates: 3552 (if approved) I. Arce 5 Intended status: Best Current Practice Quarkslab 6 Expires: January 9, 2020 July 8, 2019 8 Security Considerations for Transient Numeric Identifiers Employed in 9 Network Protocols 10 draft-gont-numeric-ids-sec-considerations-04 12 Abstract 14 For more than 30 years, a large number of implementations of the TCP/ 15 IP protocol suite have been subject to a variety of attacks, with 16 effects ranging from Denial of Service (DoS) or data injection, to 17 information leakage that could be exploited for pervasive monitoring. 18 The root of these issues has been, in many cases, the poor selection 19 of transient numeric identifiers in such protocols, usually as a 20 result of insufficient or misleading specifications. This document 21 formally updates RFC3552, such that RFCs are required to include a 22 security and privacy analysis of the transient numeric identifiers 23 they specify. 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 January 9, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 This document may not be modified, and derivative works of it may not 58 be created, and it may not be published except as an Internet-Draft. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Issues with the Specification of Identifiers . . . . . . . . 4 65 4. Common Flaws in the Generation of Transient Identifiers . . . 5 66 5. Security and Privacy Requirements for Identifiers . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 9.3. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Network protocols employ a variety of transient numeric identifiers 79 for different protocol entities, ranging from DNS Transaction IDs 80 (TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6 81 Interface Identifiers (IIDs). These identifiers usually have 82 specific properties that must be satisfied such that they do not 83 result in negative interoperability implications (e.g. uniqueness 84 during a specified period of time), and an associated failure 85 severity when such properties not met. 87 For more than 30 years, a large number of implementations of the TCP/ 88 IP protocol suite have been subject to a variety of attacks, with 89 effects ranging from Denial of Service (DoS) or data injection, to 90 information leakage that could be exploited for pervasive monitoring 91 [RFC7258]. The root of these issues has been, in many cases, the 92 poor selection of identifiers in such protocols, usually as a result 93 of insufficient or misleading specifications. While it is generally 94 trivial to identify an algorithm that can satisfy the 95 interoperability requirements for a given identifier, there exists 96 practical evidence [I-D.gont-numeric-ids-history] that doing so 97 without negatively affecting the security and/or privacy properties 98 of the aforementioned protocols is prone to error. 100 For example, implementations have been subject to security and/or 101 privacy issues resulting from: 103 o Predictable TCP sequence numbers 105 o Predictable transport protocol numbers 107 o Predictable IPv4 or IPv6 Fragment Identifiers 109 o Predictable IPv6 IIDs 111 o Predictable DNS TxIDs 113 Recent history indicates that when new protocols are standardized or 114 new protocol implementations are produced, the security and privacy 115 properties of the associated identifiers tend to be overlooked and 116 inappropriate algorithms to generate such identifiers are either 117 suggested in the specification or selected by implementers. As a 118 result, advice in this area is warranted. 120 2. Terminology 122 Identifier: 123 A data object in a protocol specification that can be used to 124 definitely distinguish a protocol object (a datagram, network 125 interface, transport protocol endpoint, session, etc) from all 126 other objects of the same type, in a given context. Identifiers 127 are usually defined as a series of bits and represented using 128 integer values. We note that these identifiers may have 129 additional requirements or properties depending on their specific 130 use in a protocol. We use the term "identifier" as a generic term 131 to refer to any data object in a protocol specification that 132 satisfies the identification property stated above. Throughout 133 this document we refer as "transient numeric identifiers" (or 134 simply as "identifiers") to the identifiers being dynamically 135 selected by a protocol. Our use of "identifier" excludes static 136 values such as "Protocol Numbers" and the like. 138 Failure Severity: 139 The consequences of a failure to comply with the interoperability 140 requirements of a given identifier. Severity considers the worst 141 potential consequence of a failure, determined by the system 142 damage and/or time lost to repair the failure. In this document 143 we define two types of failure severity: "soft" and "hard". 145 Hard Failure: 146 A hard failure is a non-recoverable condition in which a protocol 147 does not operate in the prescribed manner or it operates with 148 excessive degradation of service. For example, an established TCP 149 connection that is aborted due to an error condition constitutes, 150 from the point of view of the transport protocol, a hard failure, 151 since it enters a state from which normal operation cannot be 152 recovered. 154 Soft Failure: 155 A soft failure is a recoverable condition in which a protocol does 156 not operate in the prescribed manner but normal operation can be 157 resumed automatically in a short period of time. For example, a 158 simple packet-loss event that is subsequently recovered with a 159 retransmission can be considered a soft failure. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 3. Issues with the Specification of Identifiers 167 While assessing protocol specifications and implementations regarding 168 the use of transient numeric identifiers 169 [I-D.gont-numeric-ids-history], we found that most of the issues 170 discussed in this document arise as a result of one of the following 171 conditions: 173 o Protocol specifications that under-specify the requirements for 174 their identifiers 176 o Protocol specifications that over-specify their identifiers 178 o Protocol implementations that simply fail to comply with the 179 specified requirements 181 A number of protocol implementations (too many of them) simply 182 overlook the security and privacy implications of identifiers. 183 Examples of them are the specification of TCP port numbers in 184 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or 185 the specification of the DNS TxID in [RFC1035]. 187 On the other hand, there are a number of protocol specifications that 188 over-specify some of their associated protocol identifiers. For 189 example, [RFC4291] essentially results in link-layer addresses being 190 embedded in the IPv6 Interface Identifiers (IIDs) when the 191 interoperability requirement of uniqueness could be achieved in other 192 ways that do not result in negative security and privacy implications 194 [RFC7721]. Similarly, [RFC2460] suggested the use of a global 195 counter for the generation of Fragment Identification values, when 196 the interoperability properties of uniqueness per {Src IP, Dst IP} 197 could be achieved with other algorithms that do not result in 198 negative security and privacy implications. 200 Finally, there are protocol implementations that simply fail to 201 comply with existing protocol specifications. For example, some 202 popular operating systems (notably Microsoft Windows) still fails to 203 implement transport-protocol port randomization, as specified in 204 [RFC6056]. 206 By requiring protocol specifications to clearly specify the 207 interoperability requirements for the transient numeric identifiers 208 they specify, the constraints in the possible algorithms to generate 209 them, as well as possible over-specification of such identifiers, 210 become evident. Furthermore, requiring specifications to include a 211 security and privacy analysis of the transient numeric identifiers 212 they specify prevents the corresponding considerations from being 213 overlooked at the time a protocol is specified. 215 4. Common Flaws in the Generation of Transient Identifiers 217 This section briefly notes common flaws associated with the 218 generation of transient numeric identifiers. Such common flaws 219 include, but are not limited to: 221 o Employing trivial algorithms (e.g. global counters) that result in 222 predictable identifiers 224 o Employing the same identifier across contexts in which constancy 225 is not required 227 o Re-using identifiers across different protocols or layers of the 228 protocol stack 230 o Initializing counters or timers to constant values, when such 231 initialization is not required 233 o Employing the same increment space across different contexts 235 o Use of flawed PRNGs. 237 Employing trivial algorithms for generating the identifiers means 238 that any node that is able to sample such identifiers can easily 239 predict future identifiers employed by the victim node. For example, 240 the algorithm for Fragment Identification selection in [RFC2460] and 241 the algorithm for TCP ISN selection in [RFC0793] suffer from that 242 problem. 244 When one identifier is employed across contexts where such constancy 245 is not needed, activity correlation is made made possible. For 246 example, [RFC4291] essentially results in link-layer addresses being 247 embedded in the IPv6 Interface Identifiers (IIDs) when the 248 interoperability requirement of uniqueness could be achieved in other 249 ways. Employing an identifier that is constant across networks 250 allows for node tracking across networks. 252 Re-using identifiers across different layers or protocols ties the 253 security and privacy of the protocol re-using the identifier to the 254 security and privacy properties of the original identifier (over 255 which the protocol re-using the identifier may have no control 256 regarding its generation). Besides, when re-using an identifier 257 across protocols from different layers, the goal of of isolating the 258 properties of a layer from that of another layer is broken. Re-using 259 link-layer addresses in IPv6 addresses as specified in [RFC4291] is 260 one example of that. 262 At times, a protocol needs to convey order information (whether 263 sequence, timing, etc.). In many cases, there is no reason for the 264 corresponding counter or timer to be initialized to any specific 265 value e.g. at system bootstrap. For example, an implementations that 266 employs a counter for the Fragment Identifier [RFC8200] that gets 267 initialized to zero upon system bootstrapping will leak the number of 268 fragmented packets that this node has transmitted. Similarly, a node 269 that updates a timer to zero when bootstrapping will reveal the 270 "uptime" of the node. 272 A node that implements a per-context linear function may share the 273 increment space among different contexts (please see the "Simple 274 Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]). 275 Sharing the same increment space allows an attacker that can sample 276 identifiers in other context to e.g. learn how many identifiers have 277 been generated between two sampled values. [Sanfilippo1998a] and 278 [Sanfilippo1998b] employ shared increment spaces to leak the number 279 of fragmented packets that has been transmitted by a target node. 281 Finally, some implementations have been found to employ flawed PRNGs. 282 See e.g.[Klein2007]. 284 5. Security and Privacy Requirements for Identifiers 286 Protocol specifications that specify transient numeric identifiers 287 MUST: 289 1. Clearly specify the interoperability requirements for the 290 aforementioned identifiers. 292 2. Provide a security and privacy analysis of the aforementioned 293 identifiers. 295 3. Recommend an algorithm for generating the aforementioned 296 identifiers that mitigates security and privacy issues, such as 297 those discussed in [I-D.gont-numeric-ids-generation]. 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 This entire document is about the security and privacy implications 308 of transient numeric identifiers, and formally updates [RFC3552] such 309 that the "Security Considerations" sections of RFCs are required to 310 perform a security and privacy analysis of the transient numeric 311 identifiers they specify. 313 8. Acknowledgements 315 This document is based on the document 316 [I-D.gont-predictable-numeric-ids] co-authored by Fernando Gont and 317 Ivan Arce. Thus, the authors would like to thank (in alphabetical 318 order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, for 319 providing valuable comments on that document. 321 The authors would like to thank Diego Armando Maradona for his magic 322 and inspiration. 324 9. References 326 9.1. Normative References 328 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 329 RFC 793, DOI 10.17487/RFC0793, September 1981, 330 . 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, 334 DOI 10.17487/RFC2119, March 1997, 335 . 337 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 338 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 339 December 1998, . 341 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 342 Text on Security Considerations", BCP 72, RFC 3552, 343 DOI 10.17487/RFC3552, July 2003, 344 . 346 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 347 Protocol Port Randomization", BCP 156, RFC 6056, 348 DOI 10.17487/RFC6056, January 2011, 349 . 351 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 352 (IPv6) Specification", STD 86, RFC 8200, 353 DOI 10.17487/RFC8200, July 2017, 354 . 356 9.2. Informative References 358 [I-D.gont-predictable-numeric-ids] 359 Gont, F. and I. Arce, "Security and Privacy Implications 360 of Numeric Identifiers Employed in Network Protocols", 361 draft-gont-predictable-numeric-ids-03 (work in progress), 362 March 2019. 364 [Klein2007] 365 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 366 Predictable IP ID Vulnerability", 2007, 367 . 370 [RFC1035] Mockapetris, P., "Domain names - implementation and 371 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 372 November 1987, . 374 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 375 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 376 2006, . 378 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 379 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 380 2014, . 382 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 383 Considerations for IPv6 Address Generation Mechanisms", 384 RFC 7721, DOI 10.17487/RFC7721, March 2016, 385 . 387 [Sanfilippo1998a] 388 Sanfilippo, S., "about the ip header id", Post to Bugtraq 389 mailing-list, Mon Dec 14 1998, 390 . 392 [Sanfilippo1998b] 393 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 394 1998, . 396 9.3. Informative References 398 [I-D.gont-numeric-ids-generation] 399 Gont, F. and I. Arce, "On the Generation of Transient 400 Numeric Identifiers", draft-gont-numeric-ids-generation-03 401 (work in progress), March 2019. 403 [I-D.gont-numeric-ids-history] 404 Gont, F. and I. Arce, "Unfortunate History of Transient 405 Numeric Identifiers", draft-gont-numeric-ids-history-04 406 (work in progress), March 2019. 408 Authors' Addresses 410 Fernando Gont 411 SI6 Networks 412 Evaristo Carriego 2644 413 Haedo, Provincia de Buenos Aires 1706 414 Argentina 416 Phone: +54 11 4650 8472 417 Email: fgont@si6networks.com 418 URI: https://www.si6networks.com 420 Ivan Arce 421 Quarkslab 423 Email: iarce@quarkslab.com 424 URI: https://www.quarkslab.com