idnits 2.17.1 draft-gont-numeric-ids-sec-considerations-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 == 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 (1 February 2022) is 787 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 informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6528 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-irtf-pearg-numeric-ids-history-09 == Outdated reference: A later version (-12) exists of draft-irtf-pearg-numeric-ids-generation-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Gont 3 Internet-Draft EdgeUno 4 Updates: 3552 (if approved) I. Arce 5 Intended status: Best Current Practice Quarkslab 6 Expires: 5 August 2022 1 February 2022 8 Security Considerations for Transient Numeric Identifiers Employed in 9 Network Protocols 10 draft-gont-numeric-ids-sec-considerations-07 12 Abstract 14 Poor selection of transient numerical identifiers in protocols such 15 as the TCP/IP suite has historically led to a number of attacks on 16 implementations, ranging from Denial of Service (DoS) to data 17 injection and information leakage that can be exploited by pervasive 18 monitoring. To prevent such flaws in future protocols and 19 implementations, this document updates RFC 3552, requiring future 20 RFCs to contain a vulnerability assessment of their transient numeric 21 identifiers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 5 August 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Issues with the Specification of Transient Numeric 59 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Common Flaws in the Generation of Transient Numeric 61 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Vulnerability Assessment Requirements for Transient Numeric 63 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Network protocols employ a variety of transient numeric identifiers 75 for different protocol entities, ranging from DNS Transaction IDs 76 (TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6 77 Interface Identifiers (IIDs). These identifiers usually have 78 specific properties that must be satisfied such that they do not 79 result in negative interoperability implications (e.g., uniqueness 80 during a specified period of time), and an associated failure 81 severity when such properties not met. 83 The TCP/IP protocol suite alone has been subject to variety of 84 attacks on its transient numeric identifiers over the past 30 years 85 or more, with effects ranging from Denial of Service (DoS) or data 86 injection, to information leakage that could be exploited for 87 pervasive monitoring [RFC7258]. The root of these issues has been, 88 in many cases, the poor selection of identifiers in such protocols, 89 usually as a result of insufficient or misleading specifications. 90 While it is generally trivial to identify an algorithm that can 91 satisfy the interoperability requirements for a given identifier, 92 there exists practical evidence [I-D.irtf-pearg-numeric-ids-history] 93 that doing so without negatively affecting the security and/or 94 privacy properties of the aforementioned protocols is prone to error. 96 For example, implementations have been subject to security and/or 97 privacy issues resulting from: 99 * Predictable TCP sequence numbers (see e.g. [Morris1985], 100 [Bellovin1989], and [RFC6528]) 102 * Predictable transport protocol numbers (see e.g. [Silbersack2005] 103 and [RFC6056]) 105 * Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 106 [Sanfilippo1998a], [RFC6274], and [RFC7739]) 108 * Predictable IPv6 IIDs (see e.g. [RFC7217], [RFC7707], and 109 [RFC7721]) 111 * Predictable DNS TxIDs (see e.g. [Schuba1993] and [Klein2007]) 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 We note that the use of cryptographic techniques for confidentiality 121 and authentication may readily mitigate some of the issues arising 122 from predictable transient numeric identifiers. For example, 123 cryptographic authentication can readily mitigate data injection 124 attacks even in the presence of predictable transient numeric 125 identifiers (such as "sequence numbers"). However, use of flawed 126 algorithms (such as global counters) for generating transient numeric 127 identifiers could still result in information leakages even when 128 cryptographic techniques are employed. 130 Section 3 provides an overview of common flaws in the specification 131 of transient numeric identifiers. Section 4 provides an overview of 132 the implications of predictable transient numeric identifiers. 133 Finally, Section 5 provides key guidelines for protocol designers. 135 2. Terminology 137 Transient Numeric Identifier: 138 A data object in a protocol specification that can be used to 139 definitely distinguish a protocol object (a datagram, network 140 interface, transport protocol endpoint, session, etc) from all 141 other objects of the same type, in a given context. Transient 142 numeric identifiers are usually defined as a series of bits, and 143 represented using integer values. These identifiers are typically 144 dynamically selected, as opposed to statically-assigned numeric 145 identifiers (see e.g. [IANA-PROT]). We note that different 146 identifiers may have additional requirements or properties 147 depending on their specific use in a protocol. We use the term 148 "transient numeric identifier" (or simply "numeric identifier" or 149 "identifier" as short forms) as a generic term to refer to any 150 data object in a protocol specification that satisfies the 151 identification property stated above. 153 Failure Severity: 154 The consequences of a failure to comply with the interoperability 155 requirements of a given identifier. Severity considers the worst 156 potential consequence of a failure, determined by the system 157 damage and/or time lost to repair the failure. In this document 158 we define two types of failure severity: "soft" and "hard". 160 Hard Failure: 161 A hard failure is a non-recoverable condition in which a protocol 162 does not operate in the prescribed manner or it operates with 163 excessive degradation of service. For example, an established TCP 164 connection that is aborted due to an error condition constitutes, 165 from the point of view of the transport protocol, a hard failure, 166 since it enters a state from which normal operation cannot be 167 recovered. 169 Soft Failure: 170 A soft failure is a recoverable condition in which a protocol does 171 not operate in the prescribed manner but normal operation can be 172 resumed automatically in a short period of time. For example, a 173 simple packet-loss event that is subsequently recovered with a 174 retransmission can be considered a soft failure. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 3. Issues with the Specification of Transient Numeric Identifiers 184 A recent survey of transient numeric identifier usage in protocol 185 specifications and implementations 186 [I-D.irtf-pearg-numeric-ids-history] revealed that most of the issues 187 discussed in this document arise as a result of one of the following 188 conditions: 190 * Protocol specifications that under-specify the requirements for 191 their identifiers 193 * Protocol specifications that over-specify their identifiers 195 * Protocol implementations that simply fail to comply with the 196 specified requirements 198 Both under-specifying and over-specifying identifier contents is 199 hazardous. TCP port numbers and sequence numbers [RFC0793] and DNS 200 TxID [RFC1035] were under-specified, leading to implementations that 201 used predictable values and thus were vulnerable to numerous off-path 202 attacks. Over-specification, as for IPv6 Interface Identifiers 203 (IIDs) [RFC4291] and Fragment Identification values [RFC2460], leaves 204 implementations unable to respond to security and privacy issues 205 stemming from the mandated algorithm -- IPv6 IIDs need not expose 206 privacy-sensitive link-layer addresses, and predictable Fragment 207 Identifiers invite the same off-path attacks that plague TCP. 209 Finally, there are protocol implementations that simply fail to 210 comply with existing protocol specifications. That is, appropriate 211 guidance is provided by the protocol specification (whether the core 212 specification or or an update to it), but an implementation simply 213 fails to follow such guidance. For example, some popular operating 214 systems (notably Microsoft Windows) still fail to implement 215 transport-protocol port randomization, as specified in [RFC6056]. 217 Clear specification of the interoperability requirements for the 218 transient numeric identifiers will help identify possible algorithms 219 that could be employed to generate them, and also make evident if 220 such identifiers are being over-specified. A protocol specification 221 will usually also benefit from a vulnerability assessment of the 222 transient numeric identifiers they specify, to prevent the 223 corresponding considerations from being overlooked. 225 4. Common Flaws in the Generation of Transient Numeric Identifiers 227 This section briefly notes common flaws associated with the 228 generation of transient numeric identifiers. Such common flaws 229 include, but are not limited to: 231 * Employing trivial algorithms (e.g. global counters) that result in 232 predictable identifiers 234 * Employing the same identifier across contexts in which constancy 235 is not required 237 * Re-using identifiers across different protocols or layers of the 238 protocol stack 240 * Initializing counters or timers to constant values, when such 241 initialization is not required 243 * Employing the same increment space across different contexts 245 * Use of flawed pseudo-random number generators (PRNGs). 247 Employing trivial algorithms for generating the identifiers means 248 that any node that is able to sample such identifiers can easily 249 predict future identifiers employed by the victim node. 251 When one identifier is employed across contexts where such constancy 252 is not needed, activity correlation is made made possible. For 253 example, employing an identifier that is constant across networks 254 allows for node tracking across networks. 256 Re-using identifiers across different layers or protocols ties the 257 security and privacy properties of the protocol re-using the 258 identifier to the security and privacy properties of the original 259 identifier (over which the protocol re-using the identifier may have 260 no control regarding its generation). Besides, when re-using an 261 identifier across protocols from different layers, the goal of of 262 isolating the properties of a layer from that of another layer is 263 broken, and the vulnerability assessment may be harder to perform, 264 since the combined system, rather than each protocol in isolation 265 will have to be assessed. 267 At times, a protocol needs to convey order information (whether 268 sequence, timing, etc.). In many cases, there is no reason for the 269 corresponding counter or timer to be initialized to any specific 270 value e.g. at system bootstrap. Similarly, there may not be a need 271 for the difference between successive counted values to be a 272 predictable. 274 A node that implements a per-context linear function may share the 275 increment space among different contexts (please see the "Simple 276 Hash-Based Algorithm" in [I-D.irtf-pearg-numeric-ids-generation]). 277 Sharing the same increment space allows an attacker that can sample 278 identifiers in other context to e.g. learn how many identifiers have 279 been generated between two sampled values. 281 Finally, some implementations have been found to employ flawed PRNGs 282 (see e.g. [Klein2007]). 284 5. Vulnerability Assessment Requirements for Transient Numeric 285 Identifiers 287 Protocol specifications that employ transient numeric identifiers 288 SHOULD: 290 1. Clearly specify the interoperability requirements for the 291 aforementioned transient numeric identifiers (e.g., required 292 properties such as uniqueness, along with the failure severity if 293 such properties are not met). 295 2. Provide a vulnerability assessment of the aforementioned 296 identifiers. 298 Note: Section 8 and Section 9 of 299 [I-D.irtf-pearg-numeric-ids-generation] provide a general 300 vulnerability assessment of transient numeric identifiers, 301 along with a vulnerability assessment of common algorithms for 302 generating transient numeric identifiers. 304 3. Recommend an algorithm for generating the aforementioned 305 transient numeric identifiers that mitigates the vulnerabilities 306 identified in the previous step, such as those discussed in 307 [I-D.irtf-pearg-numeric-ids-generation]. 309 6. IANA Considerations 311 There are no IANA registries within this document. The RFC-Editor 312 can remove this section before publication of this document as an 313 RFC. 315 7. Security Considerations 317 This document formally updates [RFC3552] such that a vulnerability 318 assessment of transient numeric identifiers is performed when writing 319 the "Security Considerations" section of future RFCs. 321 8. Acknowledgements 323 The authors would like to thank Bernard Aboba, Theo de Raadt, Russ 324 Housley, Benjamin Kaduk, Charlie Kaufman, and Joe Touch, for 325 providing valuable comments on earlier versions of this document. 327 The authors would like to thank (in alphabetical order) Steven 328 Bellovin, Joseph Lorenzo Hall, Gre Norcie, for providing valuable 329 comments on [I-D.gont-predictable-numeric-ids] , on which the present 330 document is based. 332 The authors would like to thank Diego Armando Maradona for his magic 333 and inspiration. 335 9. References 337 9.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 349 Text on Security Considerations", BCP 72, RFC 3552, 350 DOI 10.17487/RFC3552, July 2003, 351 . 353 9.2. Informative References 355 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 356 Considerations for IPv6 Address Generation Mechanisms", 357 RFC 7721, DOI 10.17487/RFC7721, March 2016, 358 . 360 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 361 Interface Identifiers with IPv6 Stateless Address 362 Autoconfiguration (SLAAC)", RFC 7217, 363 DOI 10.17487/RFC7217, April 2014, 364 . 366 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 367 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 368 . 370 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 371 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 372 . 374 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 375 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 376 February 2016, . 378 [Sanfilippo1998a] 379 Sanfilippo, S., "about the ip header id", Post to Bugtraq 380 mailing-list, Mon Dec 14 1998, 381 . 383 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 384 RFC 793, DOI 10.17487/RFC0793, September 1981, 385 . 387 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 388 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 389 2012, . 391 [Bellovin1989] 392 Bellovin, S., "Security Problems in the TCP/IP Protocol 393 Suite", Computer Communications Review, vol. 19, no. 2, 394 pp. 32-48, 1989, 395 . 397 [Morris1985] 398 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 399 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 400 NJ, 1985, 401 . 403 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 404 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 405 December 1998, . 407 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 408 Protocol Port Randomization", BCP 156, RFC 6056, 409 DOI 10.17487/RFC6056, January 2011, 410 . 412 [Silbersack2005] 413 Silbersack, M.J., "Improving TCP/IP security through 414 randomization without sacrificing interoperability", 415 EuroBSDCon 2005 Conference, 2005, 416 . 419 [I-D.gont-predictable-numeric-ids] 420 Gont, F. and I. Arce, "Security and Privacy Implications 421 of Numeric Identifiers Employed in Network Protocols", 422 Work in Progress, Internet-Draft, draft-gont-predictable- 423 numeric-ids-03, 11 March 2019, 424 . 427 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 428 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 429 2014, . 431 [RFC1035] Mockapetris, P., "Domain names - implementation and 432 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 433 November 1987, . 435 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 436 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 437 2006, . 439 [Klein2007] 440 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 441 Predictable IP ID Vulnerability", 2007, 442 . 446 [Schuba1993] 447 Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME 448 SYSTEM PROTOCOL", 1993, 449 . 452 [I-D.irtf-pearg-numeric-ids-history] 453 Gont, F. and I. Arce, "Unfortunate History of Transient 454 Numeric Identifiers", Work in Progress, Internet-Draft, 455 draft-irtf-pearg-numeric-ids-history-09, 27 January 2022, 456 . 459 [I-D.irtf-pearg-numeric-ids-generation] 460 Gont, F. and I. Arce, "On the Generation of Transient 461 Numeric Identifiers", Work in Progress, Internet-Draft, 462 draft-irtf-pearg-numeric-ids-generation-07, 2 February 463 2021, . 466 [IANA-PROT] 467 IANA, "Protocol Registries", 468 . 470 Authors' Addresses 472 Fernando Gont 473 EdgeUno 474 Segurola y Habana 4310 7mo piso 475 Ciudad Autonoma de Buenos Aires 476 Buenos Aires 477 Argentina 479 Email: fernando.gont@edgeuno.com 480 URI: https://www.edgeuno.com 482 Ivan Arce 483 Quarkslab 484 Segurola y Habana 4310 7mo piso 485 Ciudad Autonoma de Buenos Aires 486 Buenos Aires 487 Argentina 489 Email: iarce@quarkslab.com 490 URI: https://www.quarkslab.com