idnits 2.17.1 draft-gont-numeric-ids-sec-considerations-00.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 (June 19, 2016) is 2839 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) == Unused Reference: 'RFC6528' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC6151' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC7098' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 6151 ** Downref: Normative reference to an Informational RFC: RFC 7098 == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-00 Summary: 5 errors (**), 0 flaws (~~), 8 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 / UTN-FRH 4 Updates: 3552 (if approved) I. Arce 5 Intended status: Best Current Practice Fundacion Sadosky 6 Expires: December 21, 2016 June 19, 2016 8 Security Considerations for Transient Numeric Identifiers Employed in 9 Network Protocols 10 draft-gont-numeric-ids-sec-considerations-00 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 identifiers in such protocols, usually as a result of an 20 insufficient or misleading specifications. This document formally 21 updates RFC3552, such that RFCs are required to perform a security 22 and privacy analysis of the transient numeric identifiers they 23 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 http://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 December 21, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 (http://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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Network protocols employ a variety of transient numeric identifiers 78 for different protocol entities, ranging from DNS Transaction IDs 79 (TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6 80 Interface Identifiers (IIDs). These identifiers usually have 81 specific properties that must be satisfied such that they do not 82 result in negative interoperability implications (e.g. uniqueness 83 during a specified period of time), and associated failure severities 84 when such properties are not met. 86 For more than 30 years, a large number of implementations of the TCP/ 87 IP protocol suite have been subject to a variety of attacks, with 88 effects ranging from Denial of Service (DoS) or data injection, to 89 information leakage that could be exploited for pervasive monitoring 90 [RFC7528]. The root of these issues has been, in many cases, the 91 poor selection of identifiers in such protocols, usually as a result 92 of an insufficient or misleading specification. While it is 93 generally trivial to identify an algorithm that can satisfy the 94 interoperability requirements for a given identifier, there exists 95 practical evidence that doing so without negatively affecting the 96 security and/or privacy properties of the aforementioned protocols is 97 prone to error. 99 For example, implementations have been subject to security and/or 100 privacy issues resulting from: 102 o Predictable TCP sequence numbers 104 o Predictable transport protocol numbers 106 o Predictable IPv4 or IPv6 Fragment Identifiers 108 o Predictable IPv6 IIDs 110 o Predictable DNS TxIDs 112 Recent history indicates that when new protocols are standardized or 113 new protocol implementations are produced, the security and privacy 114 properties of the associated identifiers tend to be overlooked and 115 inappropriate algorithms to generate identifier values are either 116 suggested in the specification or selected by implementators. As a 117 result, we believe that advice in this area is warranted. 119 2. Terminology 121 Identifier: 122 A data object in a protocol specification that can be used to 123 definetely distinguish a protocol object (a datagram, network 124 interface, transport protocol endpoint, session, etc) from all 125 other objects of the same type, in a given context. Identifiers 126 are usually defined as a series of bits and represented using 127 integer values. We note that different identifiers may have 128 additional requirements or properties depending on their specific 129 use in a protocol. We use the term "identifier" as a generic term 130 to refer to any data object in a protocol specification that 131 satisfies the identification property stated above. Throughout 132 this document we refer as "transient network identifiers" (or 133 simply as "identifiers") to the identifiers being dynamically 134 selected by a protocol. Our use of "identifier" excludes static 135 values such as "Protocol Numbers" and the like. 137 Failure Severity: 138 The consequences of a failure to comply with the interoperability 139 requirements of a given identifier. Severity considers the worst 140 potential consequence of a failure, determined by the system 141 damage and/or time lost to repair the failure. In this document 142 we define two types of failure severity: "soft" and "hard". 144 Hard Failure: 145 A hard failure is a non-recoverable condition in which a protocol 146 does not operate in the prescribed manner or it operates with 147 excessive degradation of service. For example, an established TCP 148 connection that is aborted due to an error condition constitutes, 149 from the point of view of the transport protocol, a hard failure, 150 since it enters a state from which normal operation cannot be 151 recovered. 153 Soft Failure: 154 A soft failure is a recoverable condition in which a protocol does 155 not operate in the prescribed manner but normal operation can be 156 resumed automatically in a short period of time. For example, a 157 simple packet-loss event that is subsequently recovered with a 158 retransmission can be considered a soft failure. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 3. Issues with the Specification of Identifiers 166 While assessing protocol specifications and implementations regarding 167 the use of transient numeric identifiers, we found that most of the 168 issues discussed in this document arise as a result of one of the 169 following: 171 o Protocol specifications which under-specify the requirements for 172 their identifiers 174 o Protocol specifications that over-specify their identifiers 176 o Protocol implementations that simply fail to comply with the 177 specified requirements 179 A number of protocol implementations (too many of them) simply 180 overlook the security and privacy implications of identifiers. 181 Examples of them are the specification of TCP port numbers in 182 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or 183 the specification of the DNS TxID in [RFC1035]. 185 On the other hand, there are a number of protocol specifications that 186 over-specify some of their associated protocol identifiers. For 187 example, [RFC4291] essentially results in link-layer addresses being 188 embedded in the IPv6 Interface Identifiers (IIDs) when the 189 interoperability requirement of uniqueness could be achieved in other 190 ways that do not result in negative security and privacy implications 191 [RFC7721]. Similarly, [RFC2460] suggests the use of a global counter 192 for the generation of Fragment Identification values, when the 193 interoperability properties of uniqueness per {Src IP, Dst IP} could 194 be achieved with other algorithms that do not result in negative 195 security and privacy implications. 197 Finally, there are protocol implementations that simply fail to 198 comply with existing protocol specifications. For example, some 199 popular operating systems (notably Microsoft Windows) still fail to 200 implement randomization of transport protocol ephemeral ports, as 201 specified in [RFC6056]. 203 By requiring protocol specifications to clearly specify the 204 interoperability requirements for the transient numeric identifiers 205 they specify, the constraints in the possible algorithms to generate 206 them, as well as possible over-specification of such identifiers, 207 become evident. Furthermore, requiring specifications to include a 208 security and privacy analysis of the transient numeric identifiers 209 they specify prevents the corresponding considerations from being 210 overlooked at the time a protocol is specified. 212 4. Common Flaws in the Generation of Transient Identifiers 214 This section briefly notes common flaws associated with the 215 generation of transient numeric identifiers. Such common flaws 216 include, but are not limited to: 218 o Employing trivial algorithms (e.g. global counters) that result in 219 predictable identifiers 221 o Employing the same identifier across contexts in which constancy 222 is not required 224 o Re-using identifiers across different protocols or layers of the 225 protocol stack 227 o Initializing counters or timers to constant values, when such 228 initialization is not required 230 o Employing the same increment space across different contexts 232 o Use of flawed PRNGs. 234 Employing trivial algorithms for generating the identifiers means 235 that any node that is able to sample the aforementioned identifier 236 can easily predict future identifiers employed by the victim node. 237 For example, the algorithm for Fragment Identification selection in 238 [RFC2460] and the algorithm for TCP ISN selection in [RFC0793]. 240 When one identifier is employed across contexts where such constancy 241 is not needed, activity correlation is made made possible. For 242 example, [RFC4291] essentially results in link-layer addresses being 243 embedded in the IPv6 Interface Identifiers (IIDs) when the 244 interoperability requirement of uniqueness could be achieved in other 245 ways. Employing an identifier that is constant across networks 246 allows for node tracking across networks. 248 Re-using identifiers across different layers or protocols ties the 249 security and privacy of the protocol re-using the identifier to the 250 security and privacy properties of such identifier (over which the 251 protocol re-using the identifier may have no control regarding its 252 generation). Besides, when re-using an identifier across protocols 253 from different layer, this breaks the goal of layers of isolating the 254 properties of a layer from that of another layer. The reuse of link- 255 layer addresses in IPv6 addresses specified in [RFC4291] is one 256 example of that. 258 At times, a protocol needs to convey order information (whether 259 sequence, timing, etc.). In many cases, there is no reason for the 260 corresponding counter or timer to be initialized to any specific 261 value e.g. at system bootstrap. For example, an implementations that 262 employs a counter for the Fragment Identifier [RFC2460] that gets 263 initialized to zero upon system bootstrapping will leak the amount of 264 fragmented traffic that this node has transmitted. Similarly, a node 265 that updates a timer to zero when bootstrapping will reveal the 266 "uptime" of the node. 268 When a node that implements a per-context linear function may share 269 the increment space among different contexts (please see the "Simple 270 Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]). 271 Sharing the same increment space allows an attacker that can sample 272 identifiers in other context to e.g. learn how many identifiers have 273 been generated between two sampled values. [Sanfilippo1998a] and 274 [Sanfilippo1998b] employ shared increment spaces to leak the amount 275 of fragmented traffic that has been transmitted by a target node. 277 Finally, some implementations have been found to emply flawed PRNGs. 278 See e.g.[Klein2007]. 280 5. Security and Privacy Requirements for Identifiers 282 Protocol specifications that specify transient numeric identifiers 283 MUST: 285 1. Clearly specify the interoperability requirements for the 286 aforementioned identifiers. 288 2. Provide a security and privacy analysis of the aforementioned 289 identifiers. 291 3. Recommend an algorithm for generating the aforementioned 292 identifiers that mitigates security and privacy issues, such as 293 those discussed in [I-D.gont-predictable-numeric-ids]. 295 6. IANA Considerations 297 There are no IANA registries within this document. The RFC-Editor 298 can remove this section before publication of this document as an 299 RFC. 301 7. Security Considerations 303 The entire document is about the security and privacy implications of 304 transient numeric identifiers, and formally updates [RFC3552] such 305 that the "Security Considerations" sections of RFCs are required to 306 perform a security and privacy analysis of the numeric identifiers 307 they specify. 309 8. Acknowledgements 311 This document is based on the document 312 [I-D.gont-predictable-numeric-ids] co-authored by Fernando Gont and 313 Ivan Arce. Thus, the authors would like to thank (in alphabetical 314 order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, for 315 providing valuable comments on that document. 317 9. References 319 9.1. Normative References 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 327 Text on Security Considerations", BCP 72, RFC 3552, 328 DOI 10.17487/RFC3552, July 2003, 329 . 331 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 332 RFC 793, DOI 10.17487/RFC0793, September 1981, 333 . 335 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 336 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 337 2012, . 339 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 340 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 341 December 1998, . 343 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 344 "Randomness Requirements for Security", BCP 106, RFC 4086, 345 DOI 10.17487/RFC4086, June 2005, 346 . 348 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 349 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 350 RFC 6151, DOI 10.17487/RFC6151, March 2011, 351 . 353 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 354 Flow Label for Load Balancing in Server Farms", RFC 7098, 355 DOI 10.17487/RFC7098, January 2014, 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 [Sanfilippo1998a] 366 Sanfilippo, S., "about the ip header id", Post to Bugtraq 367 mailing-list, Mon Dec 14 1998, 368 . 370 [Sanfilippo1998b] 371 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 372 1998, . 374 [I-D.gont-predictable-numeric-ids] 375 Gont, F. and I. Arce, "Security and Privacy Implications 376 of Numeric Identifiers Employed in Network Protocols", 377 draft-gont-predictable-numeric-ids-00 (work in progress), 378 February 2016. 380 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 381 DOI 10.17487/RFC1321, April 1992, 382 . 384 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 385 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 386 2006, . 388 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 389 Considerations for IPv6 Address Generation Mechanisms", 390 RFC 7721, DOI 10.17487/RFC7721, March 2016, 391 . 393 [RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN) 394 Namespace for the Hybrid Broadcast Broadband TV (HbbTV) 395 Association", RFC 7528, DOI 10.17487/RFC7528, April 2015, 396 . 398 [RFC1035] Mockapetris, P., "Domain names - implementation and 399 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 400 November 1987, . 402 [Klein2007] 403 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 404 Predictable IP ID Vulnerability", 2007, 405 . 408 Authors' Addresses 410 Fernando Gont 411 SI6 Networks / UTN-FRH 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: http://www.si6networks.com 420 Ivan Arce 421 Fundacion Dr. Manuel Sadosky 422 Av. Cordoba 744 Piso 5 Oficina I 423 Ciudad Autonoma de Buenos Aires, Buenos Aires C1054AAT 424 Argentina 426 Phone: +54 11 4328 5164 427 Email: stic@fundacionsadosky.org.ar 428 URI: http://www.fundacionsadosky.org.ar