idnits 2.17.1 draft-gont-predictable-numeric-ids-03.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 1873 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC5722' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'CPNI-TCP' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'Fyodor2004' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-6man-flowlabel-security' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'Joncheray1995' is defined on line 1275, but no explicit reference was found in the text == Unused Reference: 'RFC5927' is defined on line 1313, but no explicit reference was found in the text == Unused Reference: 'RFC7707' is defined on line 1327, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 6151 ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 7098 == Outdated reference: A later version (-05) exists of draft-eddy-rfc793bis-04 == Outdated reference: A later version (-10) exists of draft-ietf-6man-predictable-fragment-id-08 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 5 errors (**), 0 flaws (~~), 11 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: Best Current Practice I. Arce 5 Expires: September 12, 2019 Quarkslab 6 March 11, 2019 8 Security and Privacy Implications of Numeric Identifiers Employed in 9 Network Protocols 10 draft-gont-predictable-numeric-ids-03 12 Abstract 14 This document performs an analysis of the security and privacy 15 implications of different types of "numeric identifiers" used in IETF 16 protocols, and tries to categorize them based on their 17 interoperability requirements and the associated failure severity 18 when such requirements are not met. It describes a number of 19 algorithms that have been employed in real implementations to meet 20 such requirements and analyzes their security and privacy properties. 21 Additionally, it provides advice on possible algorithms that could be 22 employed to satisfy the interoperability requirements of each 23 identifier type, while minimizing the security and privacy 24 implications, thus providing guidance to protocol designers and 25 protocol implementers. Finally, it provides recommendations for 26 future protocol specifications regarding the specification of the 27 aforementioned numeric identifiers. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 12, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may not be modified, and derivative works of it may not 62 be created, and it may not be published except as an Internet-Draft. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Issues with the Specification of Identifiers . . . . . . . . 5 70 5. Timeline of Vulnerability Disclosures Related to Some Sample 71 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 6 73 5.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 7 74 6. Protocol Failure Severity . . . . . . . . . . . . . . . . . . 9 75 7. Categorizing Identifiers . . . . . . . . . . . . . . . . . . 9 76 8. Common Algorithms for Identifier Generation . . . . . . . . . 11 77 8.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 11 78 8.1.1. Simple Randomization Algorithm . . . . . . . . . . . 11 79 8.1.2. Another Simple Randomization Algorithm . . . . . . . 12 80 8.2. Category #2: Uniqueness (hard failure) . . . . . . . . . 13 81 8.3. Category #3: Uniqueness, constant within context (soft- 82 failure) . . . . . . . . . . . . . . . . . . . . . . . . 13 83 8.4. Category #4: Uniqueness, monotonically increasing within 84 context (hard failure) . . . . . . . . . . . . . . . . . 14 85 8.4.1. Predictable Linear Identifiers Algorithm . . . . . . 14 86 8.4.2. Per-context Counter Algorithm . . . . . . . . . . . . 16 87 8.4.3. Simple Hash-Based Algorithm . . . . . . . . . . . . . 18 88 8.4.4. Double-Hash Algorithm . . . . . . . . . . . . . . . . 20 89 8.4.5. Random-Increments Algorithm . . . . . . . . . . . . . 21 90 9. Common Vulnerabilities Associated with Identifiers . . . . . 23 91 9.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 23 92 9.2. Category #2: Uniqueness (hard failure) . . . . . . . . . 23 93 9.3. Category #3: Uniqueness, constant within context (soft 94 failure) . . . . . . . . . . . . . . . . . . . . . . . . 23 95 9.4. Category #4: Uniqueness, monotonically increasing within 96 context (hard failure) . . . . . . . . . . . . . . . . . 24 97 10. Security and Privacy Requirements for Identifiers . . . . . . 25 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 100 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 103 14.2. Informative References . . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 106 1. Introduction 108 Network protocols employ a variety of numeric identifiers for 109 different protocol entities, ranging from DNS Transaction IDs (TxIDs) 110 to transport protocol numbers (e.g. TCP ports) or IPv6 Interface 111 Identifiers (IIDs). These identifiers usually have specific 112 properties that must be satisfied such that they do not result in 113 negative interoperability implications (e.g. uniqueness during a 114 specified period of time), and associated failure severities when 115 such properties are not met, ranging from soft to hard failures. 117 For more than 30 years, a large number of implementations of the TCP/ 118 IP protocol suite have been subject to a variety of attacks, with 119 effects ranging from Denial of Service (DoS) or data injection, to 120 information leakage that could be exploited for pervasive monitoring 121 [RFC7528]. The root of these issues has been, in many cases, the 122 poor selection of identifiers in such protocols, usually as a result 123 of an insufficient or misleading specification. While it is 124 generally trivial to identify an algorithm that can satisfy the 125 interoperability requirements for a given identifier, there exists 126 practical evidence that doing so without negatively affecting the 127 security and/or privacy properties of the aforementioned protocols is 128 prone to error. 130 For example, implementations have been subject to security and/or 131 privacy issues resulting from: 133 o Predictable TCP sequence numbers 135 o Predictable transport protocol numbers 137 o Predictable IPv4 or IPv6 Fragment Identifiers 139 o Predictable IPv6 IIDs 141 o Predictable DNS TxIDs 142 Recent history indicates that when new protocols are standardized or 143 new protocol implementations are produced, the security and privacy 144 properties of the associated identifiers tend to be overlooked and 145 inappropriate algorithms to generate identifier values are either 146 suggested in the specification or selected by implementators. As a 147 result, we believe that advice in this area is warranted. 149 This document contains a non-exhaustive survey of identifiers 150 employed in various IETF protocols, and aims to categorize such 151 identifiers based on their interoperability requirements, and the 152 associated failure severity when such requirements are not met. 153 Subsequently, it analyzes several algorithms that have been employed 154 in real implementation to meet such requirements and analyzes their 155 security and privacy properties, and provides advice on possible 156 algorithms that could be employed to satisfy the interoperability 157 requirements of each category, while minimizing the associated 158 security and privacy implications. Finally, it provides 159 recommendations for future protocol specifications regarding the 160 specification of the aforementioned numeric identifiers. 162 2. Terminology 164 Identifier: 165 A data object in a protocol specification that can be used to 166 definetely distinguish a protocol object (a datagram, network 167 interface, transport protocol endpoint, session, etc) from all 168 other objects of the same type, in a given context. Identifiers 169 are usually defined as a series of bits and represented using 170 integer values. We note that different identifiers may have 171 additional requirements or properties depending on their specific 172 use in a protocol. We use the term "identifier" as a generic term 173 to refer to any data object in a protocol specification that 174 satisfies the identification property stated above. 176 Failure Severity: 177 The consequences of a failure to comply with the interoperability 178 requirements of a given identifier. Severity considers the worst 179 potential consequence of a failure, determined by the system 180 damage and/or time lost to repair the failure. In this document 181 we define two types of failure severity: "soft" and "hard". 183 Hard Failure: 184 A hard failure is a non-recoverable condition in which a protocol 185 does not operate in the prescribed manner or it operates with 186 excessive degradation of service. For example, an established TCP 187 connection that is aborted due to an error condition constitutes, 188 from the point of view of the transport protocol, a hard failure, 189 since it enters a state from which normal operation cannot be 190 recovered. 192 Soft Failure: 193 A soft failure is a recoverable condition in which a protocol does 194 not operate in the prescribed manner but normal operation can be 195 resumed automatically in a short period of time. For example, a 196 simple packet-loss event that is subsequently recovered with a 197 retransmission can be considered a soft failure. 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in RFC 2119 [RFC2119]. 203 3. Threat Model 205 Throughout this document, we assume an attacker does not have 206 physical or logical device to the device(s) being attacked. We 207 assume the attacker can simply send any traffic to the target 208 devices, to e.g. sample identifiers employed by such devices. 210 4. Issues with the Specification of Identifiers 212 While assessing protocol specifications regarding the use of 213 identifiers, we found that most of the issues discussed in this 214 document arise as a result of one of the following: 216 o Protocol specifications which under-specify the requirements for 217 their identifiers 219 o Protocol specifications that over-specify their identifiers 221 o Protocol implementations that simply fail to comply with the 222 specified requirements 224 A number of protocol implementations (too many of them) simply 225 overlook the security and privacy implications of identifiers. 226 Examples of them are the specification of TCP port numbers in 227 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or 228 the specification of the DNS TxID in [RFC1035]. 230 On the other hand, there are a number of protocol specifications that 231 over-specify some of their associated protocol identifiers. For 232 example, [RFC4291] essentially results in link-layer addresses being 233 embedded in the IPv6 Interface Identifiers (IIDs) when the 234 interoperability requirement of uniqueness could be achieved in other 235 ways that do not result in negative security and privacy implications 236 [RFC7721]. Similarly, [RFC2460] suggests the use of a global counter 237 for the generation of Fragment Identification values, when the 238 interoperability properties of uniqueness per {Src IP, Dst IP} could 239 be achieved with other algorithms that do not result in negative 240 security and privacy implications. 242 Finally, there are protocol implementations that simply fail to 243 comply with existing protocol specifications. For example, some 244 popular operating systems (notably Microsoft Windows) still fail to 245 implement randomization of transport protocol ephemeral ports, as 246 specified in [RFC6056]. 248 5. Timeline of Vulnerability Disclosures Related to Some Sample 249 Identifiers 251 This section contains a non-exhaustive timeline of vulnerability 252 disclosures related to some sample identifiers and other work that 253 has led to advances in this area. The goal of this timeline is to 254 illustrate: 256 o That vulnerabilities related to how the values for some 257 identifiers are generated and assigned have affected 258 implementations for an extremely long period of time. 260 o That such vulnerabilities, even when addressed for a given 261 protocol version, were later reintroduced in new versions or new 262 implementations of the same protocol. 264 o That standardization efforts that discuss and provide advice in 265 this area can have a positive effect on protocol specifications 266 and protocol implementations. 268 5.1. IPv4/IPv6 Identification 270 December 1998: 271 [Sanfilippo1998a] finds that predictable IPv4 Identification 272 values can be leveraged to count the number of packets sent by a 273 target node. [Sanfilippo1998b] explains how to leverage the same 274 vulnerability to implement a port-scanning technique known as 275 dumb/idle scan. A tool that implements this attack is publicly 276 released. 278 November 1999: 279 [Sanfilippo1999] discusses how to leverage predictable IPv4 280 Identification to uncover the rules of a number of firewalls. 282 November 1999: 283 [Bellovin2002] explains how the IPv4 Identification field can be 284 exploited to count the number of systems behind a NAT. 286 December 2003: 287 [Zalewski2003] explains a technique to perform TCP data injection 288 attack based on predictable IPv4 identification values which 289 requires less effort than TCP injection attacks performed with 290 bare TCP packets. 292 November 2005: 293 [Silbersack2005] discusses shortcoming in a number of techniques 294 to mitigate predictable IPv4 Identification values. 296 October 2007: 297 [Klein2007] describes a weakness in the pseudo random number 298 generator (PRNG) in use for the generation of the IP 299 Identification by a number of operating systems. 301 June 2011: 302 [Gont2011] describes how to perform idle scan attacks in IPv6. 304 November 2011: 305 Linux mitigates predictable IPv6 Identification values 306 [RedHat2011] [SUSE2011] [Ubuntu2011]. 308 December 2011: 309 [I-D.ietf-6man-predictable-fragment-id-08] describes the security 310 implications of predictable IPv6 Identification values, and 311 possible mitigations. 313 May 2012: 314 [Gont2012] notes that some major IPv6 implementations still employ 315 predictable IPv6 Identification values. 317 June 2015: 318 [I-D.ietf-6man-predictable-fragment-id-08] notes that some popular 319 host and router implementations still employ predictable IPv6 320 Identification values. 322 5.2. TCP Initial Sequence Numbers (ISNs) 324 September 1981: 325 [RFC0793], suggests the use of a global 32-bit ISN generator, 326 whose lower bit is incremented roughly every 4 microseconds. 327 However, such an ISN generator makes it trivial to predict the ISN 328 that a TCP will use for new connections, thus allowing a variety 329 of attacks against TCP. 331 February 1985: 333 [Morris1985] was the first to describe how to exploit predictable 334 TCP ISNs for forging TCP connections that could then be leveraged 335 for trust relationship exploitation. 337 April 1989: 338 [Bellovin1989] discussed the security implications of predictable 339 ISNs (along with a range of other protocol-based vulnerabilities). 341 February 1995: 342 [Shimomura1995] reported a real-world exploitation of the attack 343 described in 1985 (ten years before) in [Morris1985]. 345 May 1996: 346 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 347 to address predictable TCP ISNs. The same concept specified in 348 this document for TCP ISNs was later proposed for TCP ephemeral 349 ports [RFC6056], TCP Timestamps, and eventually even IPv6 350 Interface Identifiers [RFC7217]. 352 March 2001: 353 [Zalewski2001] provides a detailed analysis of statistical 354 weaknesses in some ISN generators, and includes a survey of the 355 algorithms in use by popular TCP implementations. 357 May 2001: 358 Vulnerability advisories [CERT2001] [USCERT2001] are released 359 regarding statistical weaknesses in some ISN generators, affecting 360 popular TCP/IP implementations. 362 March 2002: 363 [Zalewski2002] updates and complements [Zalewski2001]. It 364 concludes that "while some vendors [...] reacted promptly and 365 tested their solutions properly, many still either ignored the 366 issue and never evaluated their implementations, or implemented a 367 flawed solution that apparently was not tested using a known 368 approach". [Zalewski2002]. 370 February 2012: 371 [RFC6528], after 27 years of Morris' original work [Morris1985], 372 formally updates [RFC0793] to mitigate predictable TCP ISNs. 374 August 2014: 375 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 376 protocol specification, incorporates the algorithm specified in 377 [RFC6528] as the recommended algorithm for TCP ISN generation. 379 6. Protocol Failure Severity 381 Section 2 defines the concept of "Failure Severity" and two types of 382 failures that we employ throughout this document: soft and hard. 384 Our analysis of the severity of a failure is performed from the point 385 of view of the protocol in question. However, the corresponding 386 severity on the upper application or protocol may not be the same as 387 that of the protocol in question. For example, a TCP connection that 388 is aborted may or may not result in a hard failure of the upper 389 application: if the upper application can establish a new TCP 390 connection without any impact on the application, a hard failure at 391 the TCP protocol may have no severity at the application level. On 392 the other hand, if a hard failure of a TCP connection results in 393 excessive degradation of service at the application layer, it will 394 also result in a hard failure at the application. 396 7. Categorizing Identifiers 398 This section includes a non-exhaustive survey of identifiers, and 399 proposes a number of categories that can accommodate these 400 identifiers based on their interoperability requirements and their 401 failure modes (soft or hard) 403 +------------+--------------------------------------+---------------+ 404 | Identifier | Interoperability Requirements | Failure | 405 | | | Severity | 406 +------------+--------------------------------------+---------------+ 407 | IPv6 Frag | Uniqueness (for IP address pair) | Soft/Hard (1) | 408 | ID | | | 409 +------------+--------------------------------------+---------------+ 410 | IPv6 IID | Uniqueness (and constant within IPv6 | Soft (3) | 411 | | prefix) (2) | | 412 +------------+--------------------------------------+---------------+ 413 | TCP SEQ | Monotonically-increasing | Hard (4) | 414 +------------+--------------------------------------+---------------+ 415 | TCP eph. | Uniqueness (for connection ID) | Hard | 416 | port | | | 417 +------------+--------------------------------------+---------------+ 418 | IPv6 Flow | Uniqueness | None (5) | 419 | L. | | | 420 +------------+--------------------------------------+---------------+ 421 | DNS TxID | Uniqueness | None (6) | 422 +------------+--------------------------------------+---------------+ 424 Table 1: Survey of Identifiers 426 Notes: 428 (1) 429 While a single collision of Fragment ID values would simply lead 430 to a single packet drop (and hence a "soft" failure), repeated 431 collisions at high data rates might trash the Fragment ID space, 432 leading to a hard failure [RFC4963]. 434 (2) 435 While the interoperability requirements are simply that the 436 Interface ID results in a unique IPv6 address, for operational 437 reasons it is typically desirable that the resulting IPv6 address 438 (and hence the corresponding Interface ID) be constant within each 439 network [I-D.ietf-6man-default-iids] [RFC7217]. 441 (3) 442 While IPv6 Interface IDs must result in unique IPv6 addresses, 443 IPv6 Duplicate Address Detection (DAD) [RFC4862] allows for the 444 detection of duplicate Interface IDs/addresses, and hence such 445 Interface ID collisions can be recovered. 447 (4) 448 In theory there are no interoperability requirements for TCP 449 sequence numbers, since the TIME-WAIT state and TCP's "quiet time" 450 take care of old segments from previous incarnations of the 451 connection. However, a widespread optimization allows for a new 452 incarnation of a previous connection to be created if the Initial 453 Sequence Number (ISN) of the incoming SYN is larger than the last 454 sequence number seen in that direction for the previous 455 incarnation of the connection. Thus, monotonically-increasing TCP 456 sequence numbers allow for such optimization to work as expected 457 [RFC6528]. 459 (5) 460 The IPv6 Flow Label is typically employed for load sharing 461 [RFC7098], along with the Source and Destination IPv6 addresses. 462 Reuse of a Flow Label value for the same set {Source Address, 463 Destination Address} would typically cause both flows to be 464 multiplexed into the same link. However, as long as this does not 465 occur deterministically, it will not result in any negative 466 implications. 468 (6) 469 DNS TxIDs are employed, together with the Source Address, 470 Destination Address, Source Port, and Destination Port, to match 471 DNS requests and responses. However, since an implementation 472 knows which DNS requests were sent for that set of {Source 473 Address, Destination Address, Source Port, and Destination Port, 474 DNS TxID}, a collision of TxID would result, if anything, in a 475 small performance penalty (the response would be discarded when it 476 is found that it does not answer the query sent in the 477 corresponding DNS query). 479 Based on the survey above, we can categorize identifiers as follows: 481 +-----+---------------------------------------+---------------------+ 482 | Cat | Category | Sample Proto IDs | 483 | # | | | 484 +-----+---------------------------------------+---------------------+ 485 | 1 | Uniqueness (soft failure) | IPv6 Flow L., DNS | 486 | | | TxIDs | 487 +-----+---------------------------------------+---------------------+ 488 | 2 | Uniqueness (hard failure) | IPv6 Frag ID, TCP | 489 | | | ephemeral port | 490 +-----+---------------------------------------+---------------------+ 491 | 3 | Uniqueness, constant within context | IPv6 IIDs | 492 | | (soft failure) | | 493 +-----+---------------------------------------+---------------------+ 494 | 4 | Uniqueness, monotonically increasing | TCP ISN | 495 | | within context (hard failure) | | 496 +-----+---------------------------------------+---------------------+ 498 Table 2: Identifier Categories 500 We note that Category #4 could be considered a generalized case of 501 category #3, in which a monotonically increasing element is added to 502 a constant (within context) element, such that the resulting 503 identifiers are monotonically increasing within a specified context. 504 That is, the same algorithm could be employed for both #3 and #4, 505 given appropriate parameters. 507 8. Common Algorithms for Identifier Generation 509 The following subsections describe common algorithms found for 510 Protocol ID generation for each of the categories above. 512 8.1. Category #1: Uniqueness (soft failure) 514 8.1.1. Simple Randomization Algorithm 515 /* Ephemeral port selection function */ 516 id_range = max_id - min_id + 1; 517 next_id = min_id + (random() % id_range); 518 count = next_id; 520 do { 521 if(check_suitable_id(next_id)) 522 return next_id; 524 if (next_id == max_id) { 525 next_id = min_id; 526 } else { 527 next_id++; 528 } 530 count--; 531 } while (count > 0); 533 return ERROR; 535 Note: 536 random() is a function that returns a pseudo-random unsigned 537 integer number of appropriate size. Note that the output needs to 538 be unpredictable, and typical implementations of POSIX random() 539 function do not necessarily meet this requirement. See [RFC4086] 540 for randomness requirements for security. 542 The function check_suitable_id() can check, when possible, whether 543 this identifier is e.g. already in use. When already used, this 544 algorithm selects the next available protocol ID. 546 All the variables (in this and all the algorithms discussed in 547 this document) are unsigned integers. 549 8.1.2. Another Simple Randomization Algorithm 551 The following pseudo-code illustrates another algorithm for selecting 552 a random identifier in which, in the event the identifier is found to 553 be not suitable (e.g., already in use), another identifier is 554 selected randomly: 556 id_range = max_id - min_id + 1; 557 next_id = min_id + (random() % id_range); 558 count = id_range; 560 do { 561 if(check_suitable_id(next_id)) 562 return next_id; 564 next_id = min_id + (random() % id_range); 565 count--; 566 } while (count > 0); 568 return ERROR; 570 This algorithm might be unable to select an identifier (i.e., return 571 "ERROR") even if there are suitable identifiers available, when there 572 are a large number of identifiers "in use". 574 8.2. Category #2: Uniqueness (hard failure) 576 One of the most trivial approaches for achieving uniqueness for an 577 identifier (with a hard failure mode) is to implement a linear 578 function. As a result, all of the algorithms described in 579 Section 8.4 are of use for complying the requirements of this 580 identifier category. 582 8.3. Category #3: Uniqueness, constant within context (soft-failure) 584 The goal of this algorithm is to produce identifiers that are 585 constant for a given context, but that change when the aforementioned 586 context changes. 588 Keeping one value for each possible "context" may in many cases be 589 considered too onerous in terms of memory requirements. As a 590 workaround, the following algorithm employs a calculated technique 591 (as opposed to keeping state in memory) to maintain the constant 592 identifier for each given context. 594 In the following algorithm, the function F() provides (statelessly) a 595 constant identifier for each given context. 597 /* Protocol ID selection function */ 598 id_range = max_id - min_id + 1; 600 counter = 0; 602 do { 603 offset = F(CONTEXT, counter, secret_key); 604 next_id = min_id + (offset % id_range); 606 if(check_suitable_id(next_id)) 607 return next_id; 609 counter++; 611 } while (counter <= MAX_RETRIES); 613 return ERROR; 615 The function F() provides a "per-CONTEXT" constant identifier for a 616 given context. 'offset' may take any value within the storage type 617 range since we are restricting the resulting identifier to be in the 618 range [min_id, max_id] in a similar way as in the algorithm described 619 in Section 8.1.1. Collisions can be recovered by incrementing the 620 'counter' variable and recomputing F(). 622 The function F() should be a cryptographic hash function like SHA-256 623 [FIPS-SHS]. Note: MD5 [RFC1321] is considered unacceptable for F() 624 [RFC6151]. CONTEXT is the concatenation of all the elements that 625 define a given context. For example, if this algorithm is expected 626 to produce identifiers that are unique per network interface card 627 (NIC) and SLAAC autoconfiguration prefix, the CONTEXT should be the 628 concatenation of e.g. the interface index and the SLAAC 629 autoconfiguration prefix (please see [RFC7217] for an implementation 630 of this algorithm for the generation of IPv6 IIDs). 632 The secret should be chosen to be as random as possible (see 633 [RFC4086] for recommendations on choosing secrets). 635 8.4. Category #4: Uniqueness, monotonically increasing within context 636 (hard failure) 638 8.4.1. Predictable Linear Identifiers Algorithm 640 One of the most trivial ways to achieve uniqueness with a low 641 identifier reuse frequency is to produce a linear sequence. This 642 obviously assumes that each identifier will be used for a similar 643 period of time. 645 For example, the following algorithm has been employed in a number of 646 operating systems for selecting IP fragment IDs, TCP ephemeral ports, 647 etc. 649 /* Initialization at system boot time. Could be random */ 650 next_id = min_id; 651 id_inc= 1; 653 /* Identifier selection function */ 654 count = max_id - min_id + 1; 656 do { 657 if (next_id == max_id) { 658 next_id = min_id; 659 } 660 else { 661 next_id = next_id + id_inc; 662 } 664 if (check_suitable_id(next_id)) 665 return next_id; 667 count--; 669 } while (count > 0); 671 return ERROR; 673 Note: 674 check_suitable_id() is a function that checks whether the 675 resulting identifier is acceptable (e.g., whether its in use, 676 etc.). 678 For obvious reasons, this algorithm results in predicable sequences. 679 If a global counter is used (such as "next_id" in the example above), 680 a node that learns one protocol identifier can also learn or guess 681 values employed by past and future protocol instances. On the other 682 hand, when the value of increments is known (such as "1" in this 683 case), an attacker can sample two values, and learn the number of 684 identifiers that were generated in-between. 686 Where identifier reuse would lead to a hard failure, one typical 687 approach to generate unique identifiers (while minimizing the 688 security and privacy implications of predictable identifiers) is to 689 obfuscate the resulting protocol IDs by either: 691 o Replace the global counter with multiple counters (initialized to 692 a random value) 694 o Randomizing the "increments" 696 Avoiding global counters essentially means that learning one 697 identifier for a given context (e.g., one TCP ephemeral port for a 698 given {src IP, Dst IP, Dst Port}) is of no use for learning or 699 guessing identifiers for a different context (e.g., TCP ephemeral 700 ports that involve other peers). However, this may imply keeping one 701 additional variable/counter per context, which may be prohibitive in 702 some environments. The choice of id_inc has implications on both the 703 security and privacy properties of the resulting identifiers, but 704 also on the corresponding interoperability properties. On one hand, 705 minimizing the increments (as in "id_inc = 1" in our case) generally 706 minimizes the identifier reuse frequency, albeit at increased 707 predictability. On the other hand, if the increments are randomized 708 predictability of the resulting identifiers is reduced, and the 709 information leakage produced by global constant increments is 710 mitigated. 712 8.4.2. Per-context Counter Algorithm 714 One possible way to achieve similar (or even lower) identifier reuse 715 frequency while still avoiding predictable sequences would be to 716 employ a per-context counter, as opposed to a global counter. Such 717 an algorithm could be described as follows: 719 /* Initialization at system boot time. Could be random */ 720 id_inc= 1; 722 /* Identifier selection function */ 723 count = max_id - min_id + 1; 725 if(lookup_counter(CONTEXT) == ERROR){ 726 create_counter(CONTEXT); 727 } 729 next_id= lookup_counter(CONTEXT); 731 do { 732 if (next_id == max_id) { 733 next_id = min_id; 734 } 735 else { 736 next_id = next_id + id_inc; 737 } 739 if (check_suitable_id(next_id)){ 740 store_counter(CONTEXT, next_id); 741 return next_id; 742 } 744 count--; 746 } while (count > 0); 748 store_counter(CONTEXT, next_id); 749 return ERROR; 751 NOTE: 752 lookup_counter() returns the current counter for a given context, 753 or an error condition if such a counter does not exist. 755 create_counter() creates a counter for a given context, and 756 initializes such counter to a random value. 758 store_counter() saves (updates) the current counter for a given 759 context. 761 check_suitable_id() is a function that checks whether the 762 resulting identifier is acceptable (e.g., whether its in use, 763 etc.). 765 Essentially, whenever a new identifier is to be selected, the 766 algorithm checks whether there there is a counter for the 767 corresponding context. If there is, such counter is incremented to 768 obtain the new identifier, and the new identifier updates the 769 corresponding counter. If there is no counter for such context, a 770 new counter is created an initialized to a random value, and used as 771 the new identifier. 773 This algorithm produces a per-context counter, which results in one 774 linear function for each context. Since the origin of each "line" is 775 a random value, the resulting values are unknown to an off-path 776 attacker. 778 This algorithm has the following drawbacks: 780 o If, as a result of resource management, the counter for a given 781 context must be removed, the last identifier value used for that 782 context will be lost. Thus, if subsequently an identifier needs 783 to be generated for such context, that counter will need to be 784 recreated and reinitialized to random value, thus possibly leading 785 to reuse/collistion of identifiers. 787 o If the identifiers are predictable by the destination system 788 (e.g., the destination host represents the context), a vulnerable 789 host might possibly leak to third parties the identifiers used by 790 other hosts to send traffic to it (i.e., a vulnerable Host B could 791 leak to Host C the identifier values that Host A is using to send 792 packets to Host B). Appendix A of [RFC7739] describes one 793 possible scenario for such leakage in detail. 795 8.4.3. Simple Hash-Based Algorithm 797 The goal of this algorithm is to produce monotonically-increasing 798 sequences, with a randomized initial value, for each given context. 799 For example, if the identifiers being generated must be unique for 800 each {src IP, dst IP} set, then each possible combination of {src IP, 801 dst IP} should have a corresponding "next_id" value. 803 Keeping one value for each possible "context" may in many cases be 804 considered too onerous in terms of memory requirements. As a 805 workaround, the following algorithm employs a calculated technique 806 (as opposed to keeping state in memory) to maintain the random offset 807 for each possible context. 809 In the following algorithm, the function F() provides (statelessly) a 810 random offset for each given context. 812 /* Initialization at system boot time. Could be random. */ 813 counter = 0; 815 /* Protocol ID selection function */ 816 id_range = max_id - min_id + 1; 817 offset = F(CONTEXT, secret_key); 818 count = id_range; 820 do { 821 next_id = min_id + 822 (counter + offset) % id_range; 824 counter++; 826 if(check_suitable_id(next_id)) 827 return next_id; 829 count--; 831 } while (count > 0); 833 return ERROR; 835 The function F() provides a "per-CONTEXT" fixed offset within the 836 identifier space. Both the 'offset' and 'counter' variables may take 837 any value within the storage type range since we are restricting the 838 resulting identifier to be in the range [min_id, max_id] in a similar 839 way as in the algorithm described in Section 8.1.1. This allows us 840 to simply increment the 'counter' variable and rely on the unsigned 841 integer to wrap around. 843 The function F() should be a cryptographic hash function like SHA-256 844 [FIPS-SHS]. Note: MD5 [RFC1321] is considered unacceptable for F() 845 [RFC6151]. CONTEXT is the concatenation of all the elements that 846 define a given context. For example, if this algorithm is expected 847 to produce identifiers that are monotonically-increasing for each set 848 (Source IP Address, Destination IP Address), the CONTEXT should be 849 the concatenation of these two values. 851 The secret should be chosen to be as random as possible (see 852 [RFC4086] for recommendations on choosing secrets). 854 It should be noted that, since this algorithm uses a global counter 855 ("counter") for selecting identifiers, if an attacker could, e.g., 856 force a client to periodically establish a new TCP connection to an 857 attacker-controlled machine (or through an attacker-observable 858 routing path), the attacker could substract consecutive source port 859 values to obtain the number of outgoing TCP connections established 860 globally by the target host within that time period (up to wrap- 861 around issues and five-tuple collisions, of course). 863 8.4.4. Double-Hash Algorithm 865 A trade-off between maintaining a single global 'counter' variable 866 and maintaining 2**N 'counter' variables (where N is the width of the 867 result of F()) could be achieved as follows. The system would keep 868 an array of TABLE_LENGTH integers, which would provide a separation 869 of the increment of the 'counter' variable. This improvement could 870 be incorporated into the algorithm from Section 8.4.3 as follows: 872 /* Initialization at system boot time */ 873 for(i = 0; i < TABLE_LENGTH; i++) 874 table[i] = random(); 876 id_inc = 1; 878 /* Protocol ID selection function */ 879 id_range = max_id - min_id + 1; 880 offset = F(CONTEXT, secret_key1); 881 index = G(CONTEXT, secret_key2); 882 count = id_range; 884 do { 885 next_id = min_id + (offset + table[index]) % id_range; 886 table[index] = table[index] + id_inc; 888 if(check_suitable_id(next_id)) 889 return next_id; 891 count--; 893 } while (count > 0); 895 return ERROR; 897 'table[]' could be initialized with random values, as indicated by 898 the initialization code in pseudo-code above. The function G() 899 should be a cryptographic hash function. It should use the same 900 CONTEXT as F(), and a secret key value to compute a value between 0 901 and (TABLE_LENGTH-1). Alternatively, G() could take an "offset" as 902 input, and perform the exclusive-or (XOR) operation between all the 903 bytes in 'offset'. 905 The array 'table[]' assures that successive identifiers for a given 906 context will be monotonically-increasing. However, the increments 907 space is separated into TABLE_LENGTH different spaces, and thus 908 identifier reuse frequency will be (probabilistically) lower than 909 that of the algorithm in Section 8.4.3. That is, the generation of 910 identifier for one given context will not necessarily result in 911 increments in the identifiers for other contexts. 913 It is interesting to note that the size of 'table[]' does not limit 914 the number of different identifier sequences, but rather separates 915 the *increments* into TABLE_LENGTH different spaces. The identifier 916 sequence will result from adding the corresponding entry of 'table[]' 917 to the variable 'offset', which selects the actual identifier 918 sequence (as in the algorithm from Section 8.4.3). 920 An attacker can perform traffic analysis for any "increment space" 921 into which the attacker has "visibility" -- namely, the attacker can 922 force a node to generate identifiers where G(offset) identifies the 923 target "increment space". However, the attacker's ability to perform 924 traffic analysis is very reduced when compared to the predictable 925 linear identifiers (described in Section 8.4.1) and the hash-based 926 identifiers (described in Section 8.4.3). Additionally, an 927 implementation can further limit the attacker's ability to perform 928 traffic analysis by further separating the increment space (that is, 929 using a larger value for TABLE_LENGTH) and/or by randomizing the 930 increments. 932 8.4.5. Random-Increments Algorithm 934 This algorithm offers a middle ground between the algorithms that 935 select ephemeral ports randomly (such as those described in 936 Section 8.1.1 and Section 8.1.2), and those that offer obfuscation 937 but no randomization (such as those described in Section 8.4.3 and 938 Section 8.4.4). 940 /* Initialization code at system boot time. */ 941 next_id = random(); /* Initialization value */ 942 id_inc = 500; /* Determines the trade-off */ 944 /* Identifier selection function */ 945 id_range = max_id - min_id + 1; 947 count = id_range; 949 do { 950 /* Random increment */ 951 next_id = next_id + (random() % id_inc) + 1; 953 /* Keep the identifier within acceptable range */ 954 next_id = min_id + (next_id % id_range); 956 if(check_suitable_id(next_id)) 957 return next_id; 959 count--; 960 } while (count > 0); 962 return ERROR; 964 This algorithm aims at producing a monotonically increasing sequence 965 of identifiers, while avoiding the use of fixed increments, which 966 would lead to trivially predictable sequences. The value "id_inc" 967 allows for direct control of the trade-off between the level of 968 obfuscation and the ID reuse frequency. The smaller the value of 969 "id_inc", the more similar this algorithm is to a predicable, global 970 monotonically-increasing ID generation algorithm. The larger the 971 value of "id_inc", the more similar this algorithm is to the 972 algorithm described in Section 8.1.1 of this document. 974 When the identifiers wrap, there is the risk of collisions of 975 identifiers (i.e., identifier reuse). Therefore, "id_inc" should be 976 selected according to the following criteria: 978 o It should maximize the wrapping time of the identifier space. 980 o It should minimize identifier reuse frequency. 982 o It should maximize obfuscation. 984 Clearly, these are competing goals, and the decision of which value 985 of "id_inc" to use is a trade-off. Therefore, the value of "id_inc" 986 should be configurable so that system administrators can make the 987 trade-off for themselves. 989 9. Common Vulnerabilities Associated with Identifiers 991 This section analyzes common vulnerabilities associated with the 992 generation of identifiers for each of the categories identified in 993 Section 7. 995 9.1. Category #1: Uniqueness (soft failure) 997 Possible vulnerabilities associated with identifiers of this category 998 are: 1000 o Use of trivial algorithms (e.g. global counters) that generate 1001 predictable identifiers 1003 o Use of flawed PRNGs. 1005 Since the only interoperability requirement for these identifiers is 1006 uniqueness, the obvious approach to generate them is to employ a 1007 PRNG. An implementer should consult [RFC4086] regarding randomness 1008 requirements for security, and consult relevant documentation when 1009 employing a PRNG provided by the underlying system. 1011 Use algorithms other than PRNGs for generating identifiers of this 1012 category is discouraged. 1014 9.2. Category #2: Uniqueness (hard failure) 1016 As noted in Section 8.2 this category typically employs the same 1017 algorithms as Category #4, since a monotonically-increasing sequence 1018 tends to minimize the identifier reuse frequency. Therefore, the 1019 vulnerability analysis of Section 9.4 applies to this case. 1021 9.3. Category #3: Uniqueness, constant within context (soft failure) 1023 There are two main vulnerabilities that may be associated with 1024 identifiers of this category: 1026 1. Use algorithms or sources that result in predictable identifiers 1028 2. Employing the same identifier across contexts in which constantcy 1029 is not required 1031 At times, an implementation or specification may be tempted to employ 1032 a source for the identifier which is known to provide unique values. 1033 However, while unique, the associated identifiers may have other 1034 properties such as being predictable or leaking information about the 1035 node in question. For example, as noted in [RFC7721], embedding 1036 link-layer addresses for generating IPv6 IIDs not only results in 1037 predictable values, but also leaks information about the manufacturer 1038 of the network interface card. 1040 On the other hand, using an identifier across contexts where 1041 constantcy is not required can be leveraged for correlation of 1042 activities. On of the most trivial examples of this is the use of 1043 IPv6 IIDs that are constant across networks (such as IIDs that embed 1044 the underlying link-layer address). 1046 9.4. Category #4: Uniqueness, monotonically increasing within context 1047 (hard failure) 1049 A simple way to generalize algorithms employed for generating 1050 identifiers of Category #4 would be as follows: 1052 /* Identifier selection function */ 1053 count = max_id - min_id + 1; 1055 do { 1056 linear(CONTEXT)= linear(CONTEXT) + increment(); 1057 next_id= offset(CONTEXT) + linear(CONTEXT); 1059 if(check_suitable_id(next_id)) 1060 return next_id; 1062 count--; 1063 } while (count > 0); 1065 return ERROR; 1067 Essentially, an identifier (next_id) is generated by adding a linear 1068 function (linear()) to an offset value, which is unknown to the 1069 attacker, and constant for given context. 1071 The following aspects of the algorithm should be considered: 1073 o For the most part, it is the offset() function that results in 1074 identifiers that are unpredictable by an off-path attacker. While 1075 the resulting sequence will be monotonically-increasing, the use 1076 of an offset value that is unknown to the attacker makes the 1077 resulting values unknown to the attacker. 1079 o The most straightforward "stateless" implementation of offset 1080 would be that in which offset() is the result of a 1081 cryptographically-secure hash-function that takes the values that 1082 identify the context and a "secret" (not shown in the figure 1083 above) as arguments. 1085 o Another possible (but stateful) approach would be to simply 1086 generate a random offset and store it in memory, and then look-up 1087 the corresponding context when a new identifier is to be selected. 1088 The algorithm in Section 8.4.2 is essentially an implementation of 1089 this type. 1091 o The linear function is incremented according to increment(). In 1092 the most trivial case increment() could always return the constant 1093 "1". But it could also possibly return small integers such the 1094 increments are randomized. 1096 Considering the generic algorithm illustrated above we can identify 1097 the following possible vulnerabilities: 1099 o If the offset value spans more than the necessary context, 1100 identifiers could be unnecessarily predictable by other parties, 1101 since the offset value would be unnecessarily leaked to them. For 1102 example, an implementation that means to produce a per-destination 1103 counter but replaces offset() with a constant number (i.e., 1104 employs a global counter), will unnecessarily result in 1105 predictable identifiers. 1107 o The function linear() could be seen as representing the number of 1108 identifiers that have so far been generated for a given context. 1109 If linear() spans more than the necessary context, the 1110 "increments" could be leaked to other parties, thus disclosing 1111 information about the number of identifiers that have so far been 1112 generated. For example, an implementation in which linear() is 1113 implemented as a single global counter will unnecessarily leak 1114 information the number of identifiers that have been produced. 1116 o increment() determines how the linear() is incremented for each 1117 identifier that is selected. In the most trivial case, 1118 increment() will return the integer "1". However, an 1119 implementation may have increment() return a "small" integer value 1120 such that even if the current value employed by the generator is 1121 guessed (see Appendix A of [RFC7739]), the exact next identifier 1122 to be selected will be slightly harder to identify. 1124 10. Security and Privacy Requirements for Identifiers 1126 Protocol specifications that specify identifiers should: 1128 1. Clearly specify the interoperability requirements for selecting 1129 the aforementioned identifiers. 1131 2. Provide a security and privacy analysis of the aforementioned 1132 identifiers. 1134 3. Recommend an algorithm for generating the aforementioned 1135 identifiers that mitigates security and privacy issues, such as 1136 those discussed in Section 9. 1138 11. IANA Considerations 1140 There are no IANA registries within this document. The RFC-Editor 1141 can remove this section before publication of this document as an 1142 RFC. 1144 12. Security Considerations 1146 The entire document is about the security and privacy implications of 1147 identifiers. 1149 13. Acknowledgements 1151 The authors would like to thank (in alphabetical order) Steven 1152 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 1153 providing valuable comments on earlier versions of this document. 1155 The authors would like to thank Diego Armando Maradona for his magic 1156 and inspiration. 1158 14. References 1160 14.1. Normative References 1162 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1163 RFC 793, DOI 10.17487/RFC0793, September 1981, 1164 . 1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, 1168 DOI 10.17487/RFC2119, March 1997, 1169 . 1171 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1172 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1173 December 1998, . 1175 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1176 "Randomness Requirements for Security", BCP 106, RFC 4086, 1177 DOI 10.17487/RFC4086, June 2005, 1178 . 1180 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1181 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1182 2006, . 1184 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1185 Address Autoconfiguration", RFC 4862, 1186 DOI 10.17487/RFC4862, September 2007, 1187 . 1189 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1190 RFC 5722, DOI 10.17487/RFC5722, December 2009, 1191 . 1193 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1194 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1195 RFC 6151, DOI 10.17487/RFC6151, March 2011, 1196 . 1198 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 1199 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 1200 2012, . 1202 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 1203 Flow Label for Load Balancing in Server Farms", RFC 7098, 1204 DOI 10.17487/RFC7098, January 2014, 1205 . 1207 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1208 Interface Identifiers with IPv6 Stateless Address 1209 Autoconfiguration (SLAAC)", RFC 7217, 1210 DOI 10.17487/RFC7217, April 2014, 1211 . 1213 14.2. Informative References 1215 [Bellovin1989] 1216 Bellovin, S., "Security Problems in the TCP/IP Protocol 1217 Suite", Computer Communications Review, vol. 19, no. 2, 1218 pp. 32-48, 1989, 1219 . 1221 [Bellovin2002] 1222 Bellovin, S., "A Technique for Counting NATted Hosts", 1223 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 1225 [CERT2001] 1226 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 1227 TCP/IP Initial Sequence Numbers", 2001, 1228 . 1230 [CPNI-TCP] 1231 Gont, F., "Security Assessment of the Transmission Control 1232 Protocol (TCP)", United Kingdom's Centre for the 1233 Protection of National Infrastructure (CPNI) Technical 1234 Report, 2009, . 1237 [FIPS-SHS] 1238 FIPS, "Secure Hash Standard (SHS)", Federal Information 1239 Processing Standards Publication 180-4, March 2012, 1240 . 1243 [Fyodor2004] 1244 Fyodor, "Idle scanning and related IP ID games", 2004, 1245 . 1247 [Gont2011] 1248 Gont, F., "Hacking IPv6 Networks (training course)", Hack 1249 In Paris 2011 Conference Paris, France, June 2011. 1251 [Gont2012] 1252 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 1253 Conference Ottawa, Canada. May 11-12, 2012, May 2012. 1255 [I-D.eddy-rfc793bis-04] 1256 Eddy, W., "Transmission Control Protocol Specification", 1257 draft-eddy-rfc793bis-04 (work in progress), August 2014. 1259 [I-D.gont-6man-flowlabel-security] 1260 Gont, F., "Security Assessment of the IPv6 Flow Label", 1261 draft-gont-6man-flowlabel-security-03 (work in progress), 1262 March 2012. 1264 [I-D.ietf-6man-default-iids] 1265 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1266 "Recommendation on Stable IPv6 Interface Identifiers", 1267 draft-ietf-6man-default-iids-16 (work in progress), 1268 September 2016. 1270 [I-D.ietf-6man-predictable-fragment-id-08] 1271 Gont, F., "Security Implications of Predictable Fragment 1272 Identification Values", draft-ietf-6man-predictable- 1273 fragment-id-08 (work in progress), June 2015. 1275 [Joncheray1995] 1276 Joncheray, L., "A Simple Active Attack Against TCP", Proc. 1277 Fifth Usenix UNIX Security Symposium, 1995. 1279 [Klein2007] 1280 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 1281 Predictable IP ID Vulnerability", 2007, 1282 . 1285 [Morris1985] 1286 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1287 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1288 NJ, 1985, 1289 . 1291 [RedHat2011] 1292 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 1293 Important: kernel security and bug fix update", 2011, 1294 . 1296 [RFC1035] Mockapetris, P., "Domain names - implementation and 1297 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1298 November 1987, . 1300 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1301 DOI 10.17487/RFC1321, April 1992, 1302 . 1304 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1305 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1306 . 1308 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1309 Errors at High Data Rates", RFC 4963, 1310 DOI 10.17487/RFC4963, July 2007, 1311 . 1313 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 1314 DOI 10.17487/RFC5927, July 2010, 1315 . 1317 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1318 Protocol Port Randomization", BCP 156, RFC 6056, 1319 DOI 10.17487/RFC6056, January 2011, 1320 . 1322 [RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN) 1323 Namespace for the Hybrid Broadcast Broadband TV (HbbTV) 1324 Association", RFC 7528, DOI 10.17487/RFC7528, April 2015, 1325 . 1327 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1328 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1329 . 1331 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1332 Considerations for IPv6 Address Generation Mechanisms", 1333 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1334 . 1336 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1337 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1338 February 2016, . 1340 [Sanfilippo1998a] 1341 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1342 mailing-list, Mon Dec 14 1998, 1343 . 1345 [Sanfilippo1998b] 1346 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1347 1998, . 1349 [Sanfilippo1999] 1350 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1351 list, 1999, 1352 . 1354 [Shimomura1995] 1355 Shimomura, T., "Technical details of the attack described 1356 by Markoff in NYT", Message posted in USENET's 1357 comp.security.misc newsgroup Message-ID: 1358 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1359 . 1361 [Silbersack2005] 1362 Silbersack, M., "Improving TCP/IP security through 1363 randomization without sacrificing interoperability", 1364 EuroBSDCon 2005 Conference, 2005, 1365 . 1368 [SUSE2011] 1369 SUSE, "SUSE Security Announcement: Linux kernel security 1370 update (SUSE-SA:2011:046)", 2011, 1371 . 1374 [Ubuntu2011] 1375 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 1376 vulnerabilities", 2011, 1377 . 1379 [USCERT2001] 1380 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 1381 TCP/IP implementations may use statistically predictable 1382 initial sequence numbers", 2001, 1383 . 1385 [Zalewski2001] 1386 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1387 Number Analysis", 2001, 1388 . 1390 [Zalewski2002] 1391 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1392 Number Analysis - One Year Later", 2001, 1393 . 1395 [Zalewski2003] 1396 Zalewski, M., "A new TCP/IP blind data injection 1397 technique?", 2003, 1398 . 1400 Authors' Addresses 1401 Fernando Gont 1402 SI6 Networks / UTN-FRH 1403 Evaristo Carriego 2644 1404 Haedo, Provincia de Buenos Aires 1706 1405 Argentina 1407 Phone: +54 11 4650 8472 1408 Email: fgont@si6networks.com 1409 URI: http://www.si6networks.com 1411 Ivan Arce 1412 Quarkslab 1414 Email: iarce@quarkslab.com 1415 URI: https://www.quarkslab.com