idnits 2.17.1 draft-gont-numeric-ids-history-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. -- The document date (March 11, 2019) is 1874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4086' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC6151' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'CPNI-TCP' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'Fyodor2004' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'Joncheray1995' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'RFC4963' is defined on line 860, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 2073 (Obsoleted by RFC 2374) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) == Outdated reference: A later version (-05) exists of draft-eddy-rfc793bis-04 == Outdated reference: A later version (-04) exists of draft-gont-numeric-ids-generation-02 == Outdated reference: A later version (-11) exists of draft-gont-numeric-ids-sec-considerations-02 == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-02 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 4 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 Intended status: Informational I. Arce 5 Expires: September 12, 2019 Quarkslab 6 March 11, 2019 8 Unfortunate History of Transient Numeric Identifiers 9 draft-gont-numeric-ids-history-04 11 Abstract 13 This document performs an analysis of the security and privacy 14 implications of different types of "numeric identifiers" used in IETF 15 protocols, and tries to categorize them based on their 16 interoperability requirements and the associated failure severity 17 when such requirements are not met. It describes a number of 18 algorithms that have been employed in real implementations to meet 19 such requirements and analyzes their security and privacy properties. 20 Additionally, it provides advice on possible algorithms that could be 21 employed to satisfy the interoperability requirements of each 22 identifier type, while minimizing the security and privacy 23 implications, thus providing guidance to protocol designers and 24 protocol implementers. Finally, it provides recommendations for 25 future protocol specifications regarding the specification of the 26 aforementioned numeric identifiers. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may not be modified, and derivative works of it may not 61 be created, and it may not be published except as an Internet-Draft. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 5 69 5. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 8 70 6. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 10.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 79 1. Introduction 81 Network protocols employ a variety of numeric identifiers for 82 different protocol entities, ranging from DNS Transaction IDs (TxIDs) 83 to transport protocol numbers (e.g. TCP ports) or IPv6 Interface 84 Identifiers (IIDs). These identifiers usually have specific 85 properties that must be satisfied such that they do not result in 86 negative interoperability implications (e.g. uniqueness during a 87 specified period of time), and associated failure severities when 88 such properties are not met, ranging from soft to hard failures. 90 For more than 30 years, a large number of implementations of the TCP/ 91 IP protocol suite have been subject to a variety of attacks, with 92 effects ranging from Denial of Service (DoS) or data injection, to 93 information leakage that could be exploited for pervasive monitoring 94 [RFC7528]. The root of these issues has been, in many cases, the 95 poor selection of identifiers in such protocols, usually as a result 96 of an insufficient or misleading specification. While it is 97 generally trivial to identify an algorithm that can satisfy the 98 interoperability requirements for a given identifier, there exists 99 practical evidence that doing so without negatively affecting the 100 security and/or privacy properties of the aforementioned protocols is 101 prone to error. 103 For example, implementations have been subject to security and/or 104 privacy issues resulting from: 106 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. 107 [Morris1985]) 109 o Predictable ephemeral transport protocol numbers (see e.g. 110 [RFC6056] and [Silbersack2005]) 112 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 113 [RFC5722], [RFC6274], and [RFC7739]) 115 o Predictable IPv6 IIDs (see e.g. [RFC7721] and [RFC7707]) 117 o Predictable DNS TxIDs 119 Recent history indicate that when new protocols are standardized or 120 new protocol implementations are produced, the security and privacy 121 properties of the associated identifiers tend to be overlooked and 122 inappropriate algorithms to generate identifier values are either 123 suggested in the specification or selected by implementers. 125 This document contains a non-exhaustive timeline of vulnerability 126 disclosures related to some sample transient numeric identifiers and 127 other work that has led to advances in this area, with the goal of 128 illustrating that: 130 o Vulnerabilities related to how the values for some identifiers are 131 generated and assigned have affected implementations for an 132 extremely long period of time. 134 o Such vulnerabilities, even when addressed for a given protocol 135 version, were later reintroduced in new versions or new 136 implementations of the same protocol. 138 o Standardization efforts that discuss and provide advice in this 139 area can have a positive effect on protocol specifications and 140 protocol implementations. 142 Other related documents ([I-D.gont-numeric-ids-generation] and 143 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this 144 area. 146 2. Terminology 148 Identifier: 149 A data object in a protocol specification that can be used to 150 definitely distinguish a protocol object (a datagram, network 151 interface, transport protocol endpoint, session, etc) from all 152 other objects of the same type, in a given context. Identifiers 153 are usually defined as a series of bits and represented using 154 integer values. We note that different identifiers may have 155 additional requirements or properties depending on their specific 156 use in a protocol. We use the term "identifier" as a generic term 157 to refer to any data object in a protocol specification that 158 satisfies the identification property stated above. 160 Failure Severity: 161 The consequences of a failure to comply with the interoperability 162 requirements of a given identifier. Severity considers the worst 163 potential consequence of a failure, determined by the system 164 damage and/or time lost to repair the failure. In this document 165 we define two types of failure severity: "soft" and "hard". 167 Hard Failure: 168 A hard failure is a non-recoverable condition in which a protocol 169 does not operate in the prescribed manner or it operates with 170 excessive degradation of service. For example, an established TCP 171 connection that is aborted due to an error condition constitutes, 172 from the point of view of the transport protocol, a hard failure, 173 since it enters a state from which normal operation cannot be 174 recovered. 176 Soft Failure: 177 A soft failure is a recoverable condition in which a protocol does 178 not operate in the prescribed manner but normal operation can be 179 resumed automatically in a short period of time. For example, a 180 simple packet-loss event that is subsequently recovered with a 181 retransmission can be considered a soft failure. 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 3. Threat Model 189 Throughout this document, we assume an attacker does not have 190 physical or logical device to the device(s) being attacked. We 191 assume the attacker can simply send any traffic to the target 192 devices, to e.g. sample identifiers employed by such devices. 194 4. IPv4/IPv6 Identification 196 This section presents the timeline of the Identification field both 197 for IPv4 and for IPv6. The reason for presenting both cases in the 198 same section is so that it becomes evident that, while the 199 Identification value serves the same purpose in both IPv4 and IPv6, 200 the work and research done for the IPv4 case did not affect the IPv6 201 specifications or implementations. 203 The IPv4 Identification value is specified in [RFC0791], which 204 specifies the interoperability requirements for the Identification 205 field: the sender must choose the Identification field to be unique 206 for a given source address, destination address, and protocol for the 207 time the datagram (or any fragment of it) could be alive in the 208 internet. It suggests that a node may keep "a table of Identifiers, 209 one entry for each destination it has communicated with in the last 210 maximum packet lifetime for the internet", and suggests that "since 211 the Identifier field allows 65,536 different values, some host may be 212 able to simply use unique identifiers independent of destination". 213 The above may be read as a suggestion to employ per-destination or 214 global counters for the generation of Identification values. While 215 [RFC0791] does not suggest any flawed algorithm for the generation of 216 Identification values, it misses a discussion of the security and 217 privacy implications of employing predictable. This has resulted in 218 virtually all IP4 implementations generating predictable fragment 219 Identification values by means of a global counter, at least at some 220 point during the lifetime of such implementations. 222 The IPv6 Identification is specified in [RFC2460]. It serves the 223 same purpose as its IPv4 counterpart, with the only difference 224 residing in the length of the corresponding field, and that while the 225 IPv4 Identification field is part of the base IPv4 header, in the 226 IPv6 case it is part of the Fragment header (which may or may not be 227 present in an IPv6 packet). [RFC2460] states, in Section 4.5, that 228 the Identification must be different than that of any other 229 fragmented packet sent recently (within the maximum likely lifetime 230 of a packet) with the same Source Address and Destination Address. 231 Subsequently, it notes that this requirement can be met by means of a 232 wrap-around 32-bit counter that is incremented each time a packet 233 must be fragmented, and that it is an implementation choice whether 234 to use a global or a per-destination counter. Thus, the 235 implementation of the IPv6 Identification is similar to that of the 236 IPv4 case, with the only difference that in the IPv6 case the 237 suggestions to use simple counters is more explicit. 239 September 1981: 240 [RFC0791] specifies the interoperability requirements for IPv4 241 Identification value, but does not specify any requirements in the 242 area of security and privacy. 244 December 1998: 245 [Sanfilippo1998a] finds that predictable IPv4 Identification 246 values (generated by most popular implementations) can be 247 leveraged to count the number of packets sent by a target node. 248 [Sanfilippo1998b] explains how to leverage the same vulnerability 249 to implement a port-scanning technique known as dumb/idle scan. A 250 tool that implements this attack is publicly released. 252 December 1998: 253 [RFC2460] suggests that a global counter be used to generate the 254 IPv6 Identification value. 256 November 1999: 257 [Sanfilippo1999] discusses how to leverage predictable IPv4 258 Identification to uncover the rules of a number of firewalls. 260 November 1999: 261 [Bellovin2002] explains how the IPv4 Identification field can be 262 exploited to count the number of systems behind a NAT. 264 December 2003: 265 [Zalewski2003] explains a technique to perform TCP data injection 266 attack based on predictable IPv4 identification values which 267 requires less effort than TCP injection attacks performed with 268 bare TCP packets. 270 November 2005: 271 [Silbersack2005] discusses shortcoming in a number of techniques 272 to mitigate predictable IPv4 Identification values. 274 October 2007: 275 [Klein2007] describes a weakness in the pseudo random number 276 generator (PRNG) in use for the generation of the IP 277 Identification by a number of operating systems. 279 June 2011: 280 [Gont2011] describes how to perform idle scan attacks in IPv6. 282 November 2011: 284 Linux mitigates predictable IPv6 Identification values 285 [RedHat2011] [SUSE2011] [Ubuntu2011]. 287 December 2011: 288 [draft-gont-6man-predictable-fragment-id-00] describes the 289 security implications of predictable IPv6 Identification values, 290 and possible mitigations. This document is published on the 291 Standards Track, meaning to formally update [RFC2460], to 292 introduce security and privacy requirements on IPv6 Identification 293 values. 295 May 2012: 296 [Gont2012] notes that some major IPv6 implementations still employ 297 predictable IPv6 Identification values. 299 March 2013: 300 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but 301 changes the track to "BCP" (while still formally updating 302 [RFC2460]), publishing the resulting document as 303 [draft-ietf-6man-predictable-fragment-id-00]. 305 June 2013: 306 A patch that implements IPv6-based idle-scan in nmap is submitted 307 [Morbitzer2013]. 309 December 2014: 310 The 6man WG changes the status of the aforementioned IETF Internet 311 Draft to "Informational" and publishes it as 312 [draft-ietf-6man-predictable-fragment-id-02]. As a result, it no 313 longer formally updates [RFC2460]. 315 June 2015: 316 [draft-ietf-6man-predictable-fragment-id-08] notes that some 317 popular host and router implementations still employ predictable 318 IPv6 Identification values. 320 February 2016: 321 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) 322 analyzes the security and privacy implications of predictable IPv6 323 Identification values, and provides guidance for selecting an 324 algorithm to generate such values. However, being published on 325 the Informational track, it does not formally update [RFC2460]. 327 June 2016: 328 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the 329 suggestion from RFC2460 to employ a global counter for the 330 generation of IPv6 Identification values, but does not specify any 331 security and privacy requirements for the IPv6 Identification 332 value. 334 5. TCP Initial Sequence Numbers (ISNs) 336 [RFC0793] suggests that the choice of the ISN of a connection is not 337 arbitrary, but aims to reduce the chances of a stale segment from 338 being accepted by a new incarnation of a previous connection. 339 [RFC0793] suggests the use of a global 32-bit ISN generator that is 340 incremented by 1 roughly every 4 microseconds. However, as a matter 341 of fact, protection against stale segments from a previous 342 incarnation of the connection is enforced by preventing the creation 343 of a new incarnation of a previous connection before 2*MSL have 344 passed since a segment corresponding to the old incarnation was last 345 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This 346 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept 347 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are 348 monotonically increasing across connections, many stacks (e.g., 349 4.2BSD-derived) use the ISN of an incoming SYN segment to perform 350 "heuristics" that enable the creation of a new incarnation of a 351 connection while the previous incarnation is still in the TIME-WAIT 352 state (see p. 945 of [Wright1994]). This avoids an interoperability 353 problem that may arise when a node establishes connections to a 354 specific TCP end-point at a high rate [Silbersack2005]. 356 In the case of TCP, the interoperability requirements for the ISNs 357 are probably not clearly spelled out as one would expect. 358 Furthermore, the suggestion of employing a global counter in 359 [RFC0793] leads to negative security and privacy implications. 361 September 1981: 362 [RFC0793], suggests the use of a global 32-bit ISN generator, 363 whose lower bit is incremented roughly every 4 microseconds. 364 However, such an ISN generator makes it trivial to predict the ISN 365 that a TCP will use for new connections, thus allowing a variety 366 of attacks against TCP. 368 February 1985: 369 [Morris1985] was the first to describe how to exploit predictable 370 TCP ISNs for forging TCP connections that could then be leveraged 371 for trust relationship exploitation. 373 April 1989: 374 [Bellovin1989] discussed the security implications of predictable 375 ISNs (along with a range of other protocol-based vulnerabilities). 377 February 1995: 379 [Shimomura1995] reported a real-world exploitation of the attack 380 described in 1985 (ten years before) in [Morris1985]. 382 May 1996: 383 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 384 to address predictable TCP ISNs. The same concept specified in 385 this document for TCP ISNs was later proposed for TCP ephemeral 386 ports [RFC6056], TCP Timestamps, and eventually even IPv6 387 Interface Identifiers [RFC7217]. 389 March 2001: 390 [Zalewski2001] provides a detailed analysis of statistical 391 weaknesses in some ISN generators, and includes a survey of the 392 algorithms in use by popular TCP implementations. 394 May 2001: 395 Vulnerability advisories [CERT2001] [USCERT2001] are released 396 regarding statistical weaknesses in some ISN generators, affecting 397 popular TCP/IP implementations. 399 March 2002: 400 [Zalewski2002] updates and complements [Zalewski2001]. It 401 concludes that "while some vendors [...] reacted promptly and 402 tested their solutions properly, many still either ignored the 403 issue and never evaluated their implementations, or implemented a 404 flawed solution that apparently was not tested using a known 405 approach" [Zalewski2002]. 407 February 2012: 408 [RFC6528], after 27 years of Morris' original work [Morris1985], 409 formally updates [RFC0793] to mitigate predictable TCP ISNs. 411 August 2014: 412 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 413 protocol specification, incorporates the algorithm specified in 414 [RFC6528] as the recommended algorithm for TCP ISN generation. 416 6. IPv6 Interface Identifiers (IIDs) 418 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC 419 [RFC4862], DHCPv6 [RFC3315], and manual configuration. This section 420 focuses on Interface Identifiers resulting from SLAAC. 422 The Interface Identifier of stable (traditional) IPv6 addresses 423 resulting from SLAAC have traditionally resulted in the underlying 424 link-layer address being embedded in the IID. IPv6 addresses 425 resulting from SLAAC are currently required to employ Modified EUI-64 426 format identifiers, which essentially embed the underlying link-layer 427 address of the corresponding network interface. At the time, 428 employing the underlying link-layer address for the IID was seen as a 429 convenient way to obtain a unique address. However, recent awareness 430 about the security and privacy implications of this approach, and 431 thus ongoing work [I-D.ietf-6man-default-iids] at the IETF is in the 432 process of addressing this problem. 434 January 1997: 435 [RFC2073] specifies the syntax of IPv6 global addresses (referred 436 to as "An IPv6 Provider-Based Unicast Address Format" at the 437 time), consistent with the IPv6 addressing architecture specified 438 in [RFC1884]. Hosts are recommended to "generate addresses using 439 link-specific addresses as Interface ID such as 48 bit IEEE-802 440 MAC addresses". 442 July 1998: 443 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address 444 Format" (obsoleting [RFC2373]) changing the size of the Interface 445 ID to 64 bits, and specifies that that IIDs must be constructed in 446 IEEE EUI-64 format. How such identifiers are constructed becomes 447 specified in the appropriate "IPv6 over " specification such 448 as "IPv6 over Ethernet". 450 January 2001: 451 [RFC3041] recognizes the problem of network activity correlation, 452 and specifies temporary addresses. Temporary addresses are to be 453 used along with stable addresses. 455 August 2003: 456 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure 457 historic. The syntax and recommendations for the traditional 458 stable IIDs remain unchanged, though. 460 February 2006: 461 [RFC4291] is published as the latest "IP Version 6 Addressing 462 Architecture", requiring the IIDs of the traditional (stable) 463 autoconfigured addresses to employ the Modified EUI-64 format. 464 The details of constructing such interface identifiers are defined 465 in the appropriate "IPv6 over " specifications. 467 March 2008: 468 [RFC5157] provides hints regarding how patterns in IPv6 addresses 469 could be leveraged for the purpose of address scanning. 471 December 2011: 472 [draft-gont-6man-stable-privacy-addresses-00] notes that the 473 traditional scheme for generating stable addresses allows for 474 address scanning, and also does not prevent active node tracking. 476 It also specifies an alternative algorithm meant to replace IIDs 477 based on Modified EUI-64 format identifiers. 479 November 2012: 480 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a 481 working group item (as 482 [draft-ietf-6man-stable-privacy-addresses-00]). However, the 483 specified algorithm no longer formally replaces the Modified 484 EUI-64 format identifiers. 486 February 2013: 487 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages 488 IPv6 address patterns is released [Gont2013]. 490 July 2013: 491 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on 492 the security and privacy implications on all known algorithms for 493 generating IPv6 IIDs. 495 January 2014: 496 The 6man wg publishes [draft-ietf-6man-default-iids-00] 497 ("Recommendation on Stable IPv6 Interface Identifiers"), 498 recommending [I-D.ietf-6man-stable-privacy-addresses] for the 499 generation of stable addresses. 501 April 2014: 502 [RFC7217] is published, specifying "A Method for Generating 503 Semantically Opaque Interface Identifiers with IPv6 Stateless 504 Address Autoconfiguration (SLAAC)" as an alternative to (but *not* 505 replacement of) Modified EUI-64 format IIDs. 507 March 2016: 508 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning] and later 509 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network 510 Reconnaissance in IPv6 Networks", is published. 512 March 2016: 513 [RFC7721] (formerly 514 [I-D.cooper-6man-ipv6-address-generation-privacy] and later 515 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security 516 and Privacy Considerations for IPv6 Address Generation 517 Mechanisms", is published. 519 May 2016: 520 [draft-gont-6man-non-stable-iids-00] is published, with the goal 521 of specifying requirements for non-stable addresses, and updating 522 [RFC4941] such that use of only temporary addresses is allowed. 524 May 2016: 525 [draft-gont-6man-address-usage-recommendations-00] is published, 526 providing an analysis of how different aspects on an address (from 527 stability to usage mode) affect their corresponding security and 528 privacy implications, and meaning to eventually provide advice in 529 this area. 531 7. IANA Considerations 533 There are no IANA registries within this document. The RFC-Editor 534 can remove this section before publication of this document as an 535 RFC. 537 8. Security Considerations 539 The entire document is about the security and privacy implications of 540 transient numeric identifiers. 542 9. Acknowledgements 544 The authors would like to thank (in alphabetical order) Dave Crocker, 545 Christian Huitema, and Joe Touch, for providing valuable comments on 546 earlier versions of this document. 548 The authors would like to thank (in alphabetical order) Steven 549 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 550 providing valuable comments on [I-D.gont-predictable-numeric-ids], on 551 which this document is based. 553 Section 5 of this document borrows text from [RFC7528], authored by 554 Fernando Gont and Steven Bellovin. 556 The authors would like to thank Diego Armando Maradona for his magic 557 and inspiration. 559 10. References 561 10.1. Normative References 563 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 564 DOI 10.17487/RFC0791, September 1981, 565 . 567 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 568 RFC 793, DOI 10.17487/RFC0793, September 1981, 569 . 571 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 572 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 573 1992, . 575 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 576 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 577 December 1995, . 579 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. 580 Postel, "An IPv6 Provider-Based Unicast Address Format", 581 RFC 2073, DOI 10.17487/RFC2073, January 1997, 582 . 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, 586 DOI 10.17487/RFC2119, March 1997, 587 . 589 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 590 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 591 . 593 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 594 Aggregatable Global Unicast Address Format", RFC 2374, 595 DOI 10.17487/RFC2374, July 1998, 596 . 598 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 599 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 600 December 1998, . 602 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 603 Stateless Address Autoconfiguration in IPv6", RFC 3041, 604 DOI 10.17487/RFC3041, January 2001, 605 . 607 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 608 C., and M. Carney, "Dynamic Host Configuration Protocol 609 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 610 2003, . 612 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 613 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 614 August 2003, . 616 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 617 "Randomness Requirements for Security", BCP 106, RFC 4086, 618 DOI 10.17487/RFC4086, June 2005, 619 . 621 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 622 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 623 2006, . 625 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 626 Address Autoconfiguration", RFC 4862, 627 DOI 10.17487/RFC4862, September 2007, 628 . 630 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 631 Extensions for Stateless Address Autoconfiguration in 632 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 633 . 635 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 636 RFC 5722, DOI 10.17487/RFC5722, December 2009, 637 . 639 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 640 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 641 RFC 6151, DOI 10.17487/RFC6151, March 2011, 642 . 644 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 645 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 646 2012, . 648 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 649 Interface Identifiers with IPv6 Stateless Address 650 Autoconfiguration (SLAAC)", RFC 7217, 651 DOI 10.17487/RFC7217, April 2014, 652 . 654 10.2. Informative References 656 [Bellovin1989] 657 Bellovin, S., "Security Problems in the TCP/IP Protocol 658 Suite", Computer Communications Review, vol. 19, no. 2, 659 pp. 32-48, 1989, 660 . 662 [Bellovin2002] 663 Bellovin, S., "A Technique for Counting NATted Hosts", 664 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 666 [CERT2001] 667 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 668 TCP/IP Initial Sequence Numbers", 2001, 669 . 671 [CPNI-TCP] 672 Gont, F., "Security Assessment of the Transmission Control 673 Protocol (TCP)", United Kingdom's Centre for the 674 Protection of National Infrastructure (CPNI) Technical 675 Report, 2009, . 678 [draft-gont-6man-address-usage-recommendations-00] 679 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", 680 draft-gont-6man-address-usage-recommendations-00 (work in 681 progress), May 2016. 683 [draft-gont-6man-non-stable-iids-00] 684 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 685 Interface Identifiers", draft-gont-6man-non-stable-iids-00 686 (work in progress), May 2016. 688 [draft-gont-6man-predictable-fragment-id-00] 689 Gont, F., "Security Implications of Predictable Fragment 690 Identification Values", draft-gont-6man-predictable- 691 fragment-id-00 (work in progress), December 2011. 693 [draft-gont-6man-stable-privacy-addresses-00] 694 Gont, F., "A method for Generating Stable Privacy-Enhanced 695 Addresses with IPv6 Stateless Address Autoconfiguration 696 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00 697 (work in progress), December 2011. 699 [draft-ietf-6man-default-iids-00] 700 Gont, F., Cooper, A., Thaler, D., and W. Liu, 701 "Recommendation on Stable IPv6 Interface Identifiers", 702 draft-ietf-6man-default-iids-00 (work in progress), July 703 2014. 705 [draft-ietf-6man-predictable-fragment-id-00] 706 Gont, F., "Security Implications of Predictable Fragment 707 Identification Values", draft-ietf-6man-predictable- 708 fragment-id-00 (work in progress), March 2013. 710 [draft-ietf-6man-predictable-fragment-id-02] 711 Gont, F., "Security Implications of Predictable Fragment 712 Identification Values", draft-ietf-6man-predictable- 713 fragment-id-02 (work in progress), December 2014. 715 [draft-ietf-6man-predictable-fragment-id-08] 716 Gont, F., "Security Implications of Predictable Fragment 717 Identification Values", draft-ietf-6man-predictable- 718 fragment-id-08 (work in progress), June 2015. 720 [draft-ietf-6man-stable-privacy-addresses-00] 721 Gont, F., "A method for Generating Stable Privacy-Enhanced 722 Addresses with IPv6 Stateless Address Autoconfiguration 723 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 724 (work in progress), May 2012. 726 [Fyodor2004] 727 Fyodor, "Idle scanning and related IP ID games", 2004, 728 . 730 [Gont2011] 731 Gont, F., "Hacking IPv6 Networks (training course)", Hack 732 In Paris 2011 Conference Paris, France, June 2011. 734 [Gont2012] 735 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 736 Conference Ottawa, Canada. May 11-12, 2012, May 2012. 738 [Gont2013] 739 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit 740 (help wanted!)", Message posted to the IPv6 Hackers 741 mailing-list Message-ID: 742 <51184548.3030105@si6networks.com>, 1995, 743 . 746 [I-D.cooper-6man-ipv6-address-generation-privacy] 747 Cooper, A., Gont, F., and D. Thaler, "Privacy 748 Considerations for IPv6 Address Generation Mechanisms", 749 draft-cooper-6man-ipv6-address-generation-privacy-00 (work 750 in progress), July 2013. 752 [I-D.eddy-rfc793bis-04] 753 Eddy, W., "Transmission Control Protocol Specification", 754 draft-eddy-rfc793bis-04 (work in progress), August 2014. 756 [I-D.gont-6man-predictable-fragment-id] 757 Gont, F., "Security Implications of Predictable Fragment 758 Identification Values", draft-gont-6man-predictable- 759 fragment-id-03 (work in progress), January 2013. 761 [I-D.gont-6man-stable-privacy-addresses] 762 Gont, F., "A method for Generating Stable Privacy-Enhanced 763 Addresses with IPv6 Stateless Address Autoconfiguration 764 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01 765 (work in progress), March 2012. 767 [I-D.gont-numeric-ids-generation] 768 Gont, F. and I. Arce, "On the Generation of Transient 769 Numeric Identifiers", draft-gont-numeric-ids-generation-02 770 (work in progress), February 2018. 772 [I-D.gont-numeric-ids-sec-considerations] 773 Gont, F. and I. Arce, "Security Considerations for 774 Transient Numeric Identifiers Employed in Network 775 Protocols", draft-gont-numeric-ids-sec-considerations-02 776 (work in progress), February 2018. 778 [I-D.gont-opsec-ipv6-host-scanning] 779 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 780 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in 781 progress), October 2012. 783 [I-D.gont-predictable-numeric-ids] 784 Gont, F. and I. Arce, "Security and Privacy Implications 785 of Numeric Identifiers Employed in Network Protocols", 786 draft-gont-predictable-numeric-ids-02 (work in progress), 787 February 2018. 789 [I-D.ietf-6man-default-iids] 790 Gont, F., Cooper, A., Thaler, D., and S. LIU, 791 "Recommendation on Stable IPv6 Interface Identifiers", 792 draft-ietf-6man-default-iids-16 (work in progress), 793 September 2016. 795 [I-D.ietf-6man-ipv6-address-generation-privacy] 796 Cooper, A., Gont, F., and D. Thaler, "Privacy 797 Considerations for IPv6 Address Generation Mechanisms", 798 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 799 in progress), September 2015. 801 [I-D.ietf-6man-predictable-fragment-id] 802 Gont, F., "Security Implications of Predictable Fragment 803 Identification Values", draft-ietf-6man-predictable- 804 fragment-id-10 (work in progress), October 2015. 806 [I-D.ietf-6man-rfc2460bis] 807 Deering, S. and R. Hinden, "Internet Protocol, Version 6 808 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 809 in progress), May 2017. 811 [I-D.ietf-6man-stable-privacy-addresses] 812 Gont, F., "A Method for Generating Semantically Opaque 813 Interface Identifiers with IPv6 Stateless Address 814 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 815 privacy-addresses-17 (work in progress), January 2014. 817 [I-D.ietf-opsec-ipv6-host-scanning] 818 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 819 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 820 progress), August 2015. 822 [IPv6-Toolkit] 823 SI6 Networks, "SI6 Networks' IPv6 Toolkit", 824 . 826 [Joncheray1995] 827 Joncheray, L., "A Simple Active Attack Against TCP", Proc. 828 Fifth Usenix UNIX Security Symposium, 1995. 830 [Klein2007] 831 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 832 Predictable IP ID Vulnerability", 2007, 833 . 836 [Morbitzer2013] 837 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message 838 posted to the nmap-dev mailing-list, 2013, 839 . 841 [Morris1985] 842 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 843 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 844 NJ, 1985, 845 . 847 [RedHat2011] 848 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 849 Important: kernel security and bug fix update", 2011, 850 . 852 [RFC1035] Mockapetris, P., "Domain names - implementation and 853 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 854 November 1987, . 856 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 857 RFC 1948, DOI 10.17487/RFC1948, May 1996, 858 . 860 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 861 Errors at High Data Rates", RFC 4963, 862 DOI 10.17487/RFC4963, July 2007, 863 . 865 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 866 RFC 5157, DOI 10.17487/RFC5157, March 2008, 867 . 869 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 870 Protocol Port Randomization", BCP 156, RFC 6056, 871 DOI 10.17487/RFC6056, January 2011, 872 . 874 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 875 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 876 . 878 [RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN) 879 Namespace for the Hybrid Broadcast Broadband TV (HbbTV) 880 Association", RFC 7528, DOI 10.17487/RFC7528, April 2015, 881 . 883 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 884 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 885 . 887 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 888 Considerations for IPv6 Address Generation Mechanisms", 889 RFC 7721, DOI 10.17487/RFC7721, March 2016, 890 . 892 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 893 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 894 February 2016, . 896 [Sanfilippo1998a] 897 Sanfilippo, S., "about the ip header id", Post to Bugtraq 898 mailing-list, Mon Dec 14 1998, 899 . 901 [Sanfilippo1998b] 902 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 903 1998, . 905 [Sanfilippo1999] 906 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 907 list, 1999, 908 . 910 [Shimomura1995] 911 Shimomura, T., "Technical details of the attack described 912 by Markoff in NYT", Message posted in USENET's 913 comp.security.misc newsgroup Message-ID: 914 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 915 . 917 [Silbersack2005] 918 Silbersack, M., "Improving TCP/IP security through 919 randomization without sacrificing interoperability", 920 EuroBSDCon 2005 Conference, 2005, 921 . 924 [SUSE2011] 925 SUSE, "SUSE Security Announcement: Linux kernel security 926 update (SUSE-SA:2011:046)", 2011, 927 . 930 [Ubuntu2011] 931 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 932 vulnerabilities", 2011, 933 . 935 [USCERT2001] 936 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 937 TCP/IP implementations may use statistically predictable 938 initial sequence numbers", 2001, 939 . 941 [Wright1994] 942 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 943 The Implementation", Addison-Wesley, 1994. 945 [Zalewski2001] 946 Zalewski, M., "Strange Attractors and TCP/IP Sequence 947 Number Analysis", 2001, 948 . 950 [Zalewski2002] 951 Zalewski, M., "Strange Attractors and TCP/IP Sequence 952 Number Analysis - One Year Later", 2001, 953 . 955 [Zalewski2003] 956 Zalewski, M., "A new TCP/IP blind data injection 957 technique?", 2003, 958 . 960 Authors' Addresses 962 Fernando Gont 963 SI6 Networks / UTN-FRH 964 Evaristo Carriego 2644 965 Haedo, Provincia de Buenos Aires 1706 966 Argentina 968 Phone: +54 11 4650 8472 969 Email: fgont@si6networks.com 970 URI: http://www.si6networks.com 972 Ivan Arce 973 Quarkslab 975 Email: iarce@quarkslab.com 976 URI: https://www.quarkslab.com