idnits 2.17.1 draft-gont-predictable-numeric-ids-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 4, 2016) is 3002 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) == Missing Reference: 'TBD' is mentioned on line 1146, but not defined == Unused Reference: 'RFC5722' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'CPNI-TCP' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'Joncheray1995' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'RFC5927' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'I-D.gont-6man-flowlabel-security' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'Fyodor2004' is defined on line 1305, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-opsec-ipv6-host-scanning' is defined on line 1382, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 6151 ** Downref: Normative reference to an Informational RFC: RFC 7098 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) == 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 == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-09 Summary: 5 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: Best Current Practice I. Arce 5 Expires: August 7, 2016 Fundacion Sadosky 6 February 4, 2016 8 Security and Privacy Implications of Numeric Identifiers Employed in 9 Network Protocols 10 draft-gont-predictable-numeric-ids-00 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 assoiated failure severity when 18 such requirements are not met. It describes a number of algorithms 19 that have been employed in real implementations to meet such 20 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 http://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 August 7, 2016. 46 Copyright Notice 48 Copyright (c) 2016 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 (http://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. Issues with the Specification of Identifiers . . . . . . . . 5 69 4. Timeline of Vulnerability Disclosures Related to Some Sample 70 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 6 72 4.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 7 73 5. Protocol Failure Severity . . . . . . . . . . . . . . . . . . 8 74 6. Categorizing Identifiers . . . . . . . . . . . . . . . . . . 9 75 7. Common Algorithms for Identifier Generation . . . . . . . . . 11 76 7.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 11 77 7.1.1. Simple Randomization Algorithm . . . . . . . . . . . 11 78 7.1.2. Another Simple Randomization Algorithm . . . . . . . 12 79 7.2. Category #2: uniqueness (hard failure) . . . . . . . . . 13 80 7.3. Category #3: Uniqueness, constant within context (soft- 81 failure) . . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.4. Category #4: Uniqueness, monotonically increasing within 83 context (hard failure) . . . . . . . . . . . . . . . . . 14 84 7.4.1. Predictable Linear Identifiers Algorithm . . . . . . 14 85 7.4.2. Per-context Counter Algorithm . . . . . . . . . . . . 16 86 7.4.3. Simple Hash-Based Algorithm . . . . . . . . . . . . . 18 87 7.4.4. Double-Hash Algorithm . . . . . . . . . . . . . . . . 20 88 7.4.5. Random-Increments Algorithm . . . . . . . . . . . . . 21 89 8. Common Vulnerabilities Associated with Identifiers . . . . . 23 90 8.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 23 91 8.2. Category #2: uniqueness (hard failure) . . . . . . . . . 23 92 8.3. Category #3: Uniqueness, constant within context (soft 93 failure) . . . . . . . . . . . . . . . . . . . . . . . . 23 95 8.4. Category #4: Uniqueness, monotonically increasing within 96 context (hard failure) . . . . . . . . . . . . . . . . . 24 97 9. Security and Privacy Requirements for Identifiers . . . . . . 26 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 100 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 103 13.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 indicate 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. Issues with the Specification of Identifiers 205 While assessing protocol specifications regarding the use of 206 identifiers, we found that most of the issues discussed in this 207 document arise as a result of one of the following: 209 o Protocol specifications which under-specify the requirements for 210 their identifiers 212 o Protocol specifications that over-specify their identifiers 214 o Protocol implementations that simply fail to comply with the 215 specified requirements 217 A number of protocol implementations (too many of them) simply 218 overlook the security and privacy implications of identifiers. 219 Examples of them are the specification of TCP port numbers in 220 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or 221 the speification of the DNS TxID in [RFC1035]. 223 On the other hand, there are a number of protocol specifications that 224 over-specify some of their associated protocol identifiers. For 225 example, [RFC4291] essentially results in link-layer addresses being 226 embedded in the IPv6 Interface Identifiers (IIDs) when the 227 interoperability requirement of uniqueness could be achieved in other 228 ways that do not result in negative security and privacy implications 229 [I-D.ietf-6man-ipv6-address-generation-privacy]. Similarly, 230 [RFC2460] suggests the use of a global counter for the generation of 231 Fragment Identification values, when the interoperability properties 232 of uniqueness per {Src IP, Dst IP} could be achieved with other 233 algorithms that do not result in negative security and privacy 234 implications. 236 Finally, there are protocol implementations that simply fail to 237 comply with existing protocol specifications. For example, some 238 popular operating systems (notably Microsoft Windows) still fail to 239 implement randomization of transport protocol ephemeral ports, as 240 specified in [RFC6056]. 242 4. Timeline of Vulnerability Disclosures Related to Some Sample 243 Identifiers 245 This section contains a non-exhaustive timeline of vulnerability 246 disclosures related to some sample identifiers and other work that 247 has led to advances in this area. The goal of this timeline is to 248 illustrate: 250 o That vulnerabilities related to how the values for some 251 identifiers are generated and assigned have affected 252 implementations for an extremely long period of time. 254 o That such vulnerabilities, even when addressed for a given 255 protocol version, were later reintroduced in new versions or new 256 implementations of the same protocol. 258 o That standardization efforts that discuss and provide advice in 259 this area can have a positive effect on protocol specifications 260 and protocol implementations. 262 4.1. IPv4/IPv6 Identification 264 December 1998: 265 [Sanfilippo1998a] finds that predictable IPv4 Identification 266 values can be leveraged to count the number of packets sent by a 267 target node. [Sanfilippo1998b] explains how to leverage the same 268 vulnerability to implement a port-scanning technique known as 269 dumb/idle scan. A tool that implements this attack is publicly 270 released. 272 November 1999: 273 [Sanfilippo1999] discusses how to leverage predictable IPv4 274 Identification to uncover the rules of a number of firewalls. 276 November 1999: 277 [Bellovin2002] explains how the IPv4 Identification field can be 278 exploited to count the number of systems behind a NAT. 280 December 2003: 281 [Zalewski2003] explains a technique to perform TCP data injection 282 attack based on predictable IPv4 identification values which 283 requires less effort than TCP injection attacks performed with 284 bare TCP packets. 286 November 2005: 287 [Silbersack2005] discusses shortcoming in a number of techniques 288 to mitigate predictable IPv4 Identification values. 290 October 2007: 291 [Klein2007] describes a weakness in the pseudo random number 292 generator (PRNG) in use for the generation of the IP 293 Identification by a number of operating systems. 295 June 2011: 296 [Gont2011] describes how to perform idle scan attacks in IPv6. 298 November 2011: 299 Linux mitigates predictable IPv6 Identification values 300 [RedHat2011] [SUSE2011] [Ubuntu2011]. 302 December 2011: 303 [I-D.ietf-6man-predictable-fragment-id-08] describes the security 304 implications of predictable IPv6 Identification values, and 305 possible mitigations. 307 May 2012: 308 [Gont2012] notes that some major IPv6 implementations still employ 309 predictable IPv6 Identification values. 311 June 2015: 312 [I-D.ietf-6man-predictable-fragment-id-08] notes that some popular 313 host and router implementations still employ predictable IPv6 314 Identification values. 316 4.2. TCP Initial Sequence Numbers (ISNs) 318 September 1981: 319 [RFC0793], suggests the use of a global 32-bit ISN generator, 320 whose lower bit is incremented roughly every 4 microseconds. 321 However, such an ISN generator makes it trivial to predict the ISN 322 that a TCP will use for new connections, thus allowing a variety 323 of attacks against TCP. 325 February 1985: 326 [Morris1985] was the first to describe how to exploit predictable 327 TCP ISNs for forging TCP connections that could then be leveraged 328 for trust relationship exploitation. 330 April 1989: 332 [Bellovin1989] discussed the security implications of predictable 333 ISNs (along with a range of other protocol-based vulnerabilities). 335 February 1995: 336 [Shimomura1995] reported a real-world exploitation of the attack 337 described in 1985 (ten years before) in [Morris1985]. 339 May 1996: 340 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 341 to address predictable TCP ISNs. The same concept specified in 342 this document for TCP ISNs was later proposed for TCP ephemeral 343 ports [RFC6056], TCP Timestamps, and eventually even IPv6 344 Interface Identifiers [RFC7217]. 346 March 2001: 347 [Zalewski2001] provides a detailed analysis of statistical 348 weaknesses in some ISN generators, and includes a survey of the 349 algorithms in use by popular TCP implementations. 351 May 2001: 352 Vulnerability advisories [CERT2001] [USCERT2001] are released 353 regarding statistical weaknesses in some ISN generators, affecting 354 popular TCP/IP implementations. 356 March 2002: 357 [Zalewski2002] updates and complements [Zalewski2001]. It 358 concludes that "while some vendors [...] reacted promptly and 359 tested their solutions properly, many still either ignored the 360 issue and never evaluated their implementations, or implemented a 361 flawed solution that apparently was not tested using a known 362 approach". [Zalewski2002]. 364 February 2012: 365 [RFC6528], after 27 years of Morris' original work [Morris1985], 366 formally updates [RFC0793] to mitigate predictable TCP ISNs. 368 August 2014: 369 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 370 protocol specification, incorporates the algorithm specified in 371 [RFC6528] as the recommended algorithm for TCP ISN generation. 373 5. Protocol Failure Severity 375 Section 2 defines the concept of "Failure Severity" and two types of 376 failures that we employ throughout this document: soft and hard. 378 Our analysis of the severity of a failure is performed from the point 379 of view of the protocol in question. However, the corresponding 380 severity on the upper application or protocol may not be the same as 381 that of the protocol in question. For example, a TCP connection that 382 is aborted may or may not result in a hard failure of the upper 383 application: if the upper application can establish a new TCP 384 connection without any impact on the application, a hard failure at 385 the TCP protocol may have no severity at the application level. On 386 the other hand, if a hard failure of a TCP connection results in 387 excessive degradation of service at the application layer, it will 388 also result in a hard failure at the application. 390 6. Categorizing Identifiers 392 This section includes a non-exhaustive survey of identifiers, and 393 proposes a number of categories that can accommodate these 394 identifiers based on their interoperability requirements and their 395 failure modes (soft or hard) 397 +------------+--------------------------------------+---------------+ 398 | Identifier | Interoperability Requirements | Failure | 399 | | | Severity | 400 +------------+--------------------------------------+---------------+ 401 | IPv6 Frag | Uniqueness (for IP address pair) | Soft/Hard (1) | 402 | ID | | | 403 +------------+--------------------------------------+---------------+ 404 | IPv6 IID | Uniqueness (and constant within IPv6 | Soft (3) | 405 | | prefix) (2) | | 406 +------------+--------------------------------------+---------------+ 407 | TCP SEQ | Monotonically-increasing | Hard (4) | 408 +------------+--------------------------------------+---------------+ 409 | TCP eph. | Uniqueness (for connection ID) | Hard | 410 | port | | | 411 +------------+--------------------------------------+---------------+ 412 | IPv6 Flow | Uniqueness | None (5) | 413 | L. | | | 414 +------------+--------------------------------------+---------------+ 415 | DNS TxID | Uniqueness | None (6) | 416 +------------+--------------------------------------+---------------+ 418 Table 1: Survey of Identifiers 420 Notes: 422 (1) 423 While a single collision of Fragment ID values would simply lead 424 to a single packet drop (and hence a "soft" failure), repeated 425 collisions at high data rates might trash the Fragment ID space, 426 leading to a hard failure [RFC4963]. 428 (2) 429 While the interoperability requirements are simply that the 430 Interface ID results in a unique IPv6 address, for operational 431 reasons it is typically desirable that the resulting IPv6 address 432 (and hence the corresponding Interface ID) be constant within each 433 network [I-D.ietf-6man-default-iids] [RFC7217]. 435 (3) 436 While IPv6 Interface IDs must result in unique IPv6 addresses, 437 IPv6 Duplicate Address Detection (DAD) [RFC4862] allows for the 438 detection of duplicate Interface IDs/addresses, and hence such 439 Interface ID collisions can be recovered. 441 (4) 442 In theory there are no interoperability requirements for TCP 443 sequence numbers, since the TIME-WAIT state and TCP's "quiet time" 444 take care of old segments from previous incarnations of the 445 connection. However, a widespread optimization allows for a new 446 incarnation of a previous connection to be created if the Initial 447 Sequence Number (ISN) of the incoming SYN is larger than the last 448 sequence number seen in that direction for the previous 449 incarnation of the connection. Thus, monotonically-increasing TCP 450 sequence numbers allow for such optimization to work as expected 451 [RFC6528]. 453 (5) 454 The IPv6 Flow Label is typically employed for load sharing 455 [RFC7098], along with the Source and Destination IPv6 addresses. 456 Reuse of a Flow Label value for the same set {Source Address, 457 Destination Address} would typically cause both flows to be 458 multiplexed into the same link. However, as long as this does not 459 occur deterministically, it will not result in any negative 460 implications. 462 (6) 463 DNS TxIDs are employed, together with the Source Address, 464 Destination Address, Source Port, and Destination Port, to match 465 DNS requests and responses. However, since an implementation 466 knows which DNS requests were sent for that set of {Source 467 Address, Destination Address, Source Port, and Destination Port, 468 DNS TxID}, a collision of TxID would result, if anything, in a 469 small performance penalty (the response would be discarded when it 470 is found that it does not answer the query sent in the 471 corresponding DNS query). 473 Based on the survey above, we can categorize identifiers as follows: 475 +-----+---------------------------------------+---------------------+ 476 | Cat | Category | Sample Proto IDs | 477 | # | | | 478 +-----+---------------------------------------+---------------------+ 479 | 1 | Uniqueness (soft failure) | IPv6 Flow L., DNS | 480 | | | TxIDs | 481 +-----+---------------------------------------+---------------------+ 482 | 2 | Uniqueness (hard failure) | IPv6 Frag ID, TCP | 483 | | | ephemeral port | 484 +-----+---------------------------------------+---------------------+ 485 | 3 | Uniqueness, constant within context | IPv6 IIDs | 486 | | (soft failure) | | 487 +-----+---------------------------------------+---------------------+ 488 | 4 | Uniqueness, monotonically increasing | TCP ISN | 489 | | within context (hard failure) | | 490 +-----+---------------------------------------+---------------------+ 492 Table 2: Identifier Categories 494 We note that Category #4 could be considered a generalized case of 495 category #3, in which a monotonically increasing element is added to 496 a constant (within context) element, such that the resulting 497 identifiers are monotonically increasing within a specified context. 498 That is, the same algorithm could be employed for both #3 and #4, 499 given appropriate parameters. 501 7. Common Algorithms for Identifier Generation 503 The following subsections describe common algorithms found for 504 Protocol ID generation for each of the categories above. 506 7.1. Category #1: Uniqueness (soft failure) 508 7.1.1. Simple Randomization Algorithm 509 /* Ephemeral port selection function */ 510 id_range = max_id - min_id + 1; 511 next_id = min_id + (random() % id_range); 512 count = next_id; 514 do { 515 if(check_suitable_id(next_id)) 516 return next_id; 518 if (next_id == max_id) { 519 next_id = min_id; 520 } else { 521 next_id++; 522 } 524 count--; 525 } while (count > 0); 527 return ERROR; 529 Note: 530 random() is a function that returns a pseudo-random unsigned 531 integer number of appropriate size. Note that the output needs to 532 be unpredictable, and typical implementations of POSIX random() 533 function do not necessarily meet this requirement. See [RFC4086] 534 for randomness requirements for security. 536 The function check_suitable_id() can check, when possible, whether 537 this identifier is e.g. already in use. When already used, this 538 algorithm selects the next available protocol ID. 540 All the variables (in this and all the algorithms discussed in 541 this document) are unsigned integers. 543 7.1.2. Another Simple Randomization Algorithm 545 The following pseudo-code illustrates another algorithm for selecting 546 a random identifier in which, in the event the identifier is found to 547 be not suitable (e.g., already in use), another identifier is 548 selected randomly: 550 id_range = max_id - min_id + 1; 551 next_id = min_id + (random() % id_range); 552 count = id_range; 554 do { 555 if(check_suitable_id(next_id)) 556 return next_id; 558 next_id = min_id + (random() % id_range); 559 count--; 560 } while (count > 0); 562 return ERROR; 564 This algorithm might be unable to select an identifier (i.e., return 565 "ERROR") even if there are suitable identifiers available, when there 566 are a large number of identifiers "in use". 568 7.2. Category #2: uniqueness (hard failure) 570 One of the most trivial approaches for achieving uniqueness for an 571 identifier (with a hard failure mode) is to implement a linear 572 function. As a result, all of the algorithms described in 573 Section 7.4 are of use for complying the requirements of this 574 identifier category. 576 7.3. Category #3: Uniqueness, constant within context (soft-failure) 578 The goal of this algorithm is to produce identifiers that are 579 constant for a given context, but that change when the aforementioned 580 context changes. 582 Keeping one value for each possible "context" may in many cases be 583 considered too onerous in terms of memory requirements. As a 584 workaround, the following algorithm employs a calculated technique 585 (as opposed to keeping state in memory) to maintain the constant 586 identifier for each given context. 588 In the following algorithm, the function F() provides (statelessly) a 589 constant identifier for each given context. 591 /* Protocol ID selection function */ 592 id_range = max_id - min_id + 1; 594 counter = 0; 596 do { 597 offset = F(CONTEXT, counter, secret_key); 598 next_id = min_id + (offset % id_range); 600 if(check_suitable_id(next_id)) 601 return next_id; 603 counter++; 605 } while (counter <= MAX_RETRIES); 607 return ERROR; 609 The function F() provides a "per-CONTEXT" constant identifier for a 610 given context. 'offset' may take any value within the storage type 611 range since we are restricting the resulting identifier to be in the 612 range [min_id, max_id] in a similar way as in the algorithm described 613 in Section 7.1.1. Collisions can be recovered by incrementing the 614 'counter' variable and recomputing F(). 616 The function F() should be a cryptographic hash function like SHA-256 617 [FIPS-SHS]. Note: MD5 [RFC1321] is considered unacceptable for F() 618 [RFC6151]. CONTEXT is the concatenation of all the elements that 619 define a given context. For example, if this algorithm is expected 620 to produce identifiers that are unique per network interface card 621 (NIC) and SLAAC autoconfiguration prefix, the CONTEXT should be the 622 concatenation of e.g. the interface index and the SLAAC 623 autoconfiguration prefix (please see [RFC7217] for an implementation 624 of this algorithm for the generation of IPv6 IIDs). 626 The secret should be chosen to be as random as possible (see 627 [RFC4086] for recommendations on choosing secrets). 629 7.4. Category #4: Uniqueness, monotonically increasing within context 630 (hard failure) 632 7.4.1. Predictable Linear Identifiers Algorithm 634 One of the most trivial ways to achieve uniqueness with a low 635 identifier reuse frequency is to produce a linear sequence. This 636 obviously assumes that each identifier will be used for a similar 637 period of time. 639 For example, the following algorithm has been employed in a number of 640 operating systems for selecting IP fragment IDs, TCP ephemeral ports, 641 etc. 643 /* Initialization at system boot time. Could be random */ 644 next_id = min_id; 645 id_inc= 1; 647 /* Identifier selection function */ 648 count = max_id - min_id + 1; 650 do { 651 if (next_id == max_id) { 652 next_id = min_id; 653 } 654 else { 655 next_id = next_ifd + id_inc; 656 } 658 if (check_suitable_id(next_id)) 659 return next_id; 661 count--; 663 } while (count > 0); 665 return ERROR; 667 Note: 668 check_suitable_id() is a function that checks whether the 669 resulting identifier is acceptable (e.g., whether its in use, 670 etc.). 672 For obvious reasons, this algorithm results in predicable sequences. 673 If a global counter is used (such as "next_id" in the example above), 674 a node that learns one protocol identifier can also learn or guess 675 values employed by past and future protocol instances. On the other 676 hand, when the value of increments is known (such as "1" in this 677 case), an attacker can sample two values, and learn the number of 678 identifiers that were generated in-between. 680 Where identifier reuse would lead to a hard failure, one typical 681 approach to generate unique identifiers (while minimizing the 682 security and privacy implications of predictable identifiers) is to 683 obfuscate the resulting protocol IDs by either: 685 o Replace the global counter with multiple counters (initialized to 686 a random value) 688 o Randomizing the "increments" 690 Avoiding global counters essentially means that learning one 691 identifier for a given context (e.g., one TCP ephemeral port for a 692 given {src IP, Dst IP, Dst Port}) is of no use for learning or 693 guessing identifiers for a different context (e.g., TCP ephemeral 694 ports that involve other peers). However, this may imply keeping one 695 additional variable/counter per context, which may be prohibitive in 696 some environments. The choice of id_inc has implications on both the 697 security and privacy properties of the resulting identifiers, but 698 also on the corresponding interoperability properties. On one hand, 699 minimizing the increments (as in "id_inc = 1" in our case) generally 700 minimizes the identifier reuse frequency, albeit at increased 701 predictability. On the other hand, if the increments are randomized 702 predictability of the resulting identifiers is reduced, and the 703 information leakage produced by global constant increments is 704 mitigated. 706 7.4.2. Per-context Counter Algorithm 708 One possible way to achieve similar (or even lower) identifier reuse 709 frequency while still avoiding predictable sequences would be to 710 employ a per-context counter, as opposed to a global counter. Such 711 an algorithm could be described as follows: 713 /* Initialization at system boot time. Could be random */ 714 id_inc= 1; 716 /* Identifier selection function */ 717 count = max_id - min_id + 1; 719 if(lookup_counter(CONTEXT) == ERROR){ 720 create_counter(CONTEXT); 721 } 723 next_id= lookup_counter(CONTEXT); 725 do { 726 if (next_id == max_id) { 727 next_id = min_id; 728 } 729 else { 730 next_id = next_id + id_inc; 731 } 733 if (check_suitable_id(next_id)){ 734 store_counter(CONTEXT, next_id); 735 return next_id; 736 } 738 count--; 740 } while (count > 0); 742 store_counter(CONTEXT, next_id); 743 return ERROR; 745 NOTE: 746 lookup_counter() returns the current counter for a given context, 747 or an error condition if such a counter does nto exist. 749 create_counter() creates a counter for a given context, and 750 initializes such counter to a random value. 752 store_counter() saves (updates) the current counter for a given 753 context. 755 check_suitable_id() is a function that checks whether the 756 resulting identifier is acceptable (e.g., whether its in use, 757 etc.). 759 Essentially, whenever a new identifier is to be selected, the 760 algorithm checks whether there there is a counter for the 761 corresponding context. If there is, such counter is incremented to 762 obtain the new identifier, and the new identifier updates the 763 corresponding counter. If there is no counter for such context, a 764 new counter is created an initialized to a random value, and used as 765 the new identifier. 767 This algorithm produces a per-context counter, which results in one 768 linear function for each context. Since the origin of each "line" is 769 a random value, the resulting values are unknown to an off-path 770 attacker. 772 This algorithm has the following drawbacks: 774 o If, as a result of resource management, the counter for a given 775 context must be removed, the last identifier value used for that 776 context will be lost. Thus, if subsequently an identifier needs 777 to be generated for such context, that counter will need to be 778 recreated and reinitialized to random value, thus possibly leading 779 to reuse/collistion of identifiers. 781 o If the identifiers are predictable by the destination system 782 (e.g., the destination host represents the context), a vulnerable 783 host might possibly leak to third parties the identifiers used by 784 other hosts to send traffic to it (i.e., a vulnerable Host B could 785 leak to Host C the identifier values that Host A is using to send 786 packets to Host B). Appendix A of [RFC7739] describes one 787 possible scenario for such leakage in detail. 789 7.4.3. Simple Hash-Based Algorithm 791 The goal of this algorithm is to produce monotonically-increasing 792 sequences, with a randomized initial value, for each given context. 793 For example, if the identifiers being generated must be unique for 794 each {src IP, dst IP} set, then each possible combination of {src IP, 795 dst IP} should have a corresponding "next_id" value. 797 Keeping one value for each possible "context" may in many cases be 798 considered too onerous in terms of memory requirements. As a 799 workaround, the following algorithm employs a calculated technique 800 (as opposed to keeping state in memory) to maintain the random offset 801 for each possible context. 803 In the following algorithm, the function F() provides (statelessly) a 804 random offset for each given context. 806 /* Initialization at system boot time. Could be random. */ 807 counter = 0; 809 /* Protocol ID selection function */ 810 id_range = max_id - min_id + 1; 811 offset = F(CONTEXT, secret_key); 812 count = id_range; 814 do { 815 next_id = min_id + 816 (counter + offset) % id_range; 818 counter++; 820 if(check_suitable_id(next_id)) 821 return next_id; 823 count--; 825 } while (count > 0); 827 return ERROR; 829 The function F() provides a "per-CONTEXT" fixed offset within the 830 identifier space. Both the 'offset' and 'counter' variables may take 831 any value within the storage type range since we are restricting the 832 resulting identifier to be in the range [min_id, max_id] in a similar 833 way as in the algorithm described in Section 7.1.1. This allows us 834 to simply increment the 'counter' variable and rely on the unsigned 835 integer to wrap around. 837 The function F() should be a cryptographic hash function like SHA-256 838 [FIPS-SHS]. Note: MD5 [RFC1321] is considered unacceptable for F() 839 [RFC6151]. CONTEXT is the concatenation of all the elements that 840 define a given context. For example, if this algorithm is expected 841 to produce identifiers that are monotonically-increasing for each set 842 (Source IP Address, Destination IP Address), the CONTEXT should be 843 the concatenation of these two values. 845 The secret should be chosen to be as random as possible (see 846 [RFC4086] for recommendations on choosing secrets). 848 It should be noted that, since this algorithm uses a global counter 849 ("counter") for selecting identifiers, if an attacker could, e.g., 850 force a client to periodically establish a new TCP connection to an 851 attacker-controlled machine (or through an attacker-observable 852 routing path), the attacker could substract consecutive source port 853 values to obtain the number of outgoing TCP connections established 854 globally by the target host within that time period (up to wrap- 855 around issues and five-tuple collisions, of course). 857 7.4.4. Double-Hash Algorithm 859 A trade-off between maintaining a single global 'counter' variable 860 and maintaining 2**N 'counter' variables (where N is the width of the 861 result of F()) could be achieved as follows. The system would keep 862 an array of TABLE_LENGTH integers, which would provide a separation 863 of the increment of the 'counter' variable. This improvement could 864 be incorporated into the algorithm from Section 7.4.3 as follows: 866 /* Initialization at system boot time */ 867 for(i = 0; i < TABLE_LENGTH; i++) 868 table[i] = random(); 870 id_inc = 1; 872 /* Protocol ID selection function */ 873 id_range = max_id - min_id + 1; 874 offset = F(CONTEXT, secret_key1); 875 index = G(CONTEXT, secret_key2); 876 count = id_range; 878 do { 879 next_id = min_id + (offset + table[index]) % id_range; 880 table[index] = table[index] + id_inc; 882 if(check_suitable_id(next_id)) 883 return next_id; 885 count--; 887 } while (count > 0); 889 return ERROR; 891 'table[]' could be initialized with random values, as indicated by 892 the initialization code in pseudo-code above. The function G() 893 should be a cryptographic hash function. It should use the same 894 CONTEXT as F(), and a secret key value to compute a value between 0 895 and (TABLE_LENGTH-1). Alternatively, G() could take an "offset" as 896 input, and perform the exclusive-or (XOR) operation between all the 897 bytes in 'offset'. 899 The array 'table[]' assures that successive identifiers for a given 900 context will be monotonically-increasing. However, the increments 901 space is separated into TABLE_LENGTH different spaces, and thus 902 identifier reuse frequency will be (probabilistically) lower than 903 that of the algorithm in Section 7.4.3. That is, the generation of 904 identifier for one given context will not necessarily result in 905 increments in the identifiers for other contexts. 907 It is interesting to note that the size of 'table[]' does not limit 908 the number of different identifier sequences, but rather separates 909 the *increments* into TABLE_LENGTH different spaces. The identifier 910 sequence will result from adding the corresponding entry of 'table[]' 911 to the variable 'offset', which selects the actual identifier 912 sequence (as in the algorithm from Section 7.4.3). 914 An attacker can perform traffic analysis for any "increment space" 915 into which the attacker has "visibility" -- namely, the attacker can 916 force a node to generate identifiers where G(offset) identifies the 917 target "increment space". However, the attacker's ability to perform 918 traffic analysis is very reduced when compared to the predictable 919 linear identifiers (described in Section 7.4.1) and the hash-based 920 identifiers (described in Section 7.4.3). Additionally, an 921 implementation can further limit the attacker's ability to perform 922 traffic analysis by further separating the increment space (that is, 923 using a larger value for TABLE_LENGTH) and/or by randomizing the 924 increments. 926 7.4.5. Random-Increments Algorithm 928 This algorithm offers a middle ground between the algorithms that 929 select ephemeral ports randomly (such as those described in Sections 930 Section 7.1.1 and Section 7.1.2), and those that offer obfuscation 931 but no randomization (such as those described in Sections 932 Section 7.4.3 and Section 7.4.4). 934 /* Initialization code at system boot time. */ 935 next_id = random(); /* Initialization value */ 936 id_inc = 500; /* Determines the trade-off */ 938 /* Identifier selection function */ 939 id_range = max_id - min_id + 1; 941 count = id_range; 943 do { 944 /* Random increment */ 945 next_id = next_id + (random() % id_increment) + 1; 947 /* Keep the identifier within acceptable range */ 948 next_id = min_id + (next_id % id_range); 950 if(check_suitable_id(next_id)) 951 return next_id; 953 count--; 954 } while (count > 0); 956 return ERROR; 958 This algorithm aims at producing a monotonically increasing sequence 959 of identifiers, while avoiding the use of fixed increments, which 960 would lead to trivially predictable sequences. The value "id_inc" 961 allows for direct control of the trade-off between the level of 962 obfuscation and the ID reuse frequency. The smaller the value of 963 "id_inc", the more similar this algorithm is to a predicable, global 964 monotonically-increasing ID generation algorithm. The larger the 965 value of "id_inc", the more similar this algorithm is to the 966 algorithm described in Section 7.1.1 of this document. 968 When the identifiers wrap, there is the risk of collisions of 969 identifiers (i.e., identifier reuse). Therefore, "id_inc" should be 970 selected according to the following criteria: 972 o It should maximize the wrapping time of the identifier space. 974 o It should minimize identifier reuse frequency. 976 o It should maximize obfuscation. 978 Clearly, these are competing goals, and the decision of which value 979 of "id_inc" to use is a trade-off. Therefore, the value of "id_inc" 980 should be configurable so that system administrators can make the 981 trade-off for themselves. 983 8. Common Vulnerabilities Associated with Identifiers 985 This section analyzes common vulnerabilities associated with the 986 generation of identifiers for each of the categories identified in 987 Section 6. 989 8.1. Category #1: Uniqueness (soft failure) 991 Possible vulnerabilities associated with identifiers of this category 992 are: 994 o Use of trivial algorithms (e.g. global counters) that generate 995 predictable identifiers 997 o Use of flawed PRNGs. 999 Since the only interoperability requirement for these identifiers is 1000 uniqueness, the obvious approach to generate them is to employ a 1001 PRNG. An implementer should consult [RFC4086] regarding randomness 1002 requirements for security, and consult relevant documentation when 1003 employing a PRNG provided by the underlying system. 1005 Use algorithms other than PRNGs for generating identifiers of this 1006 category is discouraged. 1008 8.2. Category #2: uniqueness (hard failure) 1010 As noted in Section 7.2 this category typically employs the same 1011 algorithms as Category #4, since a monotonically-increasing sequence 1012 tends to minimize the identifier reuse frequency. Therefore, the 1013 vulnerability analysis of Section 8.4 applies to this case. 1015 8.3. Category #3: Uniqueness, constant within context (soft failure) 1017 There are two main vulnerabilities that may be associated with 1018 identifiers of this category: 1020 1. Use algorithms or sources that result in predictable identifiers 1022 2. Employing the same identifier across contexts in which constantcy 1023 is not required 1025 At times, an implementation or specification may be tempted to employ 1026 a source for the identifier which is known to provide unique values. 1027 However, while unique, the associated identifiers may have other 1028 properties such as being predictable or leaking information about the 1029 node in question. For example, as noted in 1030 [I-D.ietf-6man-ipv6-address-generation-privacy], embedding link-layer 1031 addresses for generating IPv6 IIDs not only results in predictable 1032 values, but also leaks information about the manufacturer of the 1033 network interface card. 1035 On the other hand, using an identifier across contexts where 1036 constantcy is not required can be leveraged for correlation of 1037 activities. On of the most trivial examples of this is the use of 1038 IPv6 IIDs that are constant across networks (such as IIDs that embed 1039 the underlying link-layer address). 1041 8.4. Category #4: Uniqueness, monotonically increasing within context 1042 (hard failure) 1044 A simple way to generalize algorithms employed for generating 1045 identifiers of Category #4 would be as follows: 1047 /* Identifier selection function */ 1048 count = max_id - min_id + 1; 1050 do { 1051 linear(CONTEXT)= linear(CONTEXT) + increment(); 1052 next_id= offset(CONTEXT) + linear(CONTEXT); 1054 if(check_suitable_id(next_id)) 1055 return next_id; 1057 count--; 1058 } while (count > 0); 1060 return ERROR; 1062 Essentially, an identifier (next_id) is generated by adding a linear 1063 function (linear()) to an offset value, which is unknown to the 1064 attacker, and constant for given context. 1066 The following aspects of the algorithm should be considered: 1068 o For the most part, it is the offset() function that results in 1069 identifiers that are unpredictable by an off-path attacker. While 1070 the resulting sequence will be monotonically-increasing, the use 1071 of an offset value that is unknown to the attacker makes the 1072 resulting values unknown to the attacker. 1074 o The most straightforward "stateless" implementation of offset 1075 would be that in which offset() is the result of a 1076 cryptographically-secure hash-function that takes the values that 1077 identify the context and a "secret" (not shown in the figure 1078 above) as arguments. 1080 o Another possible (but stateful) approach would be to simply 1081 generate a random offset and store it in memory, and then look-up 1082 the corresponding context when a new identifier is to be selected. 1083 The algorithm in Section 7.4.2 is essentially an implementation of 1084 this type. 1086 o The linear function is incremented according to increment(). In 1087 the most trivial case increment() could always return the constant 1088 "1". But it could also possibly return small integers such the 1089 increments are randomized. 1091 Considering the generic algorithm illustrated above we can identify 1092 the following possible vulnerabilities: 1094 o If the offset value spans more than the necessary context, 1095 identifiers could be unnecessarily predictable by other parties, 1096 since the offset value would be unnecessarily leaked to them. For 1097 example, an implementation that means to produce a per-destination 1098 counter but replaces offset() with a constant number (i.e., 1099 employs a global counter), will unnecessarily result in 1100 predictable identifiers. 1102 o The function linear() could be seen as representing the number of 1103 identifiers that have so far been generated for a given context. 1104 If linear() spans more than the necessary context, the 1105 "increments" could be leaked to other parties, thus disclosing 1106 information about the number of identifiers that have so far been 1107 generated. For example, an implementation in which linear() is 1108 implemented as a single global counter will unnecessarily leak 1109 information the number of identifiers that have been produced. 1111 o increment() determines how the linear() is incremented for each 1112 identifier that is selected. In the most trivial case, 1113 increment() will return the integer "1". However, an 1114 implementation may have increment() return a "small" integer value 1115 such that even if the current value employed by the generator is 1116 guessed (see Appendix A of [RFC7739]), the exact next identifier 1117 to be selected will be slightly harder to identify. 1119 9. Security and Privacy Requirements for Identifiers 1121 Protocol specifications that specify identifiers should: 1123 1. Clearly specify the interoperability requirements for selecting 1124 the aforementioned identifiers. 1126 2. Provide a security and privacy analysis of the aforementioned 1127 identifiers. 1129 3. Recommend an algorithm for generating the aforementioned 1130 identifiers that mitigates security and privacy issues, such as 1131 those discussed in Section 8. 1133 10. IANA Considerations 1135 There are no IANA registries within this document. The RFC-Editor 1136 can remove this section before publication of this document as an 1137 RFC. 1139 11. Security Considerations 1141 The entire document is about the security and privacy implications of 1142 identifiers. 1144 12. Acknowledgements 1146 The authors would like to thank (in alphabetical order) [TBD] for 1147 providing valuable comments on earlier versions of this document. 1149 13. References 1151 13.1. Normative References 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC 2119, 1155 DOI 10.17487/RFC2119, March 1997, 1156 . 1158 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1159 RFC 793, DOI 10.17487/RFC0793, September 1981, 1160 . 1162 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 1163 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 1164 2012, . 1166 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1167 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1168 December 1998, . 1170 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1171 "Randomness Requirements for Security", BCP 106, RFC 4086, 1172 DOI 10.17487/RFC4086, June 2005, 1173 . 1175 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1176 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1177 2006, . 1179 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1180 Address Autoconfiguration", RFC 4862, 1181 DOI 10.17487/RFC4862, September 2007, 1182 . 1184 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1185 RFC 5722, DOI 10.17487/RFC5722, December 2009, 1186 . 1188 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1189 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1190 RFC 6151, DOI 10.17487/RFC6151, March 2011, 1191 . 1193 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1194 Interface Identifiers with IPv6 Stateless Address 1195 Autoconfiguration (SLAAC)", RFC 7217, 1196 DOI 10.17487/RFC7217, April 2014, 1197 . 1199 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 1200 Flow Label for Load Balancing in Server Farms", RFC 7098, 1201 DOI 10.17487/RFC7098, January 2014, 1202 . 1204 13.2. Informative References 1206 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1207 DOI 10.17487/RFC1321, April 1992, 1208 . 1210 [RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN) 1211 Namespace for the Hybrid Broadcast Broadband TV (HbbTV) 1212 Association", RFC 7528, DOI 10.17487/RFC7528, April 2015, 1213 . 1215 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1216 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1217 . 1219 [CPNI-TCP] 1220 Gont, F., "Security Assessment of the Transmission Control 1221 Protocol (TCP)", United Kingdom's Centre for the 1222 Protection of National Infrastructure (CPNI) Technical 1223 Report, 2009, . 1226 [Zalewski2001] 1227 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1228 Number Analysis", 2001, 1229 . 1231 [Zalewski2002] 1232 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1233 Number Analysis - One Year Later", 2001, 1234 . 1236 [Bellovin1989] 1237 Bellovin, S., "Security Problems in the TCP/IP Protocol 1238 Suite", Computer Communications Review, vol. 19, no. 2, 1239 pp. 32-48, 1989, . 1242 [Joncheray1995] 1243 Joncheray, L., "A Simple Active Attack Against TCP", Proc. 1244 Fifth Usenix UNIX Security Symposium, 1995. 1246 [Morris1985] 1247 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1248 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1249 NJ, 1985, . 1252 [USCERT2001] 1253 US-CERT, , "US-CERT Vulnerability Note VU#498440: Multiple 1254 TCP/IP implementations may use statistically predictable 1255 initial sequence numbers", 2001, 1256 . 1258 [CERT2001] 1259 CERT, , "CERT Advisory CA-2001-09: Statistical Weaknesses 1260 in TCP/IP Initial Sequence Numbers", 2001, 1261 . 1263 [Shimomura1995] 1264 Shimomura, T., "Technical details of the attack described 1265 by Markoff in NYT", Message posted in USENET's 1266 comp.security.misc newsgroup Message-ID: 1267 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1268 . 1270 [I-D.eddy-rfc793bis-04] 1271 Eddy, W., "Transmission Control Protocol Specification", 1272 draft-eddy-rfc793bis-04 (work in progress), August 2014. 1274 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1275 Protocol Port Randomization", BCP 156, RFC 6056, 1276 DOI 10.17487/RFC6056, January 2011, 1277 . 1279 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 1280 DOI 10.17487/RFC5927, July 2010, 1281 . 1283 [I-D.gont-6man-flowlabel-security] 1284 Gont, F., "Security Assessment of the IPv6 Flow Label", 1285 draft-gont-6man-flowlabel-security-03 (work in progress), 1286 March 2012. 1288 [RFC1035] Mockapetris, P., "Domain names - implementation and 1289 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1290 November 1987, . 1292 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1293 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1294 February 2016, . 1296 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1297 Errors at High Data Rates", RFC 4963, 1298 DOI 10.17487/RFC4963, July 2007, 1299 . 1301 [Bellovin2002] 1302 Bellovin, S., "A Technique for Counting NATted Hosts", 1303 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 1305 [Fyodor2004] 1306 Fyodor, , "Idle scanning and related IP ID games", 2004, 1307 . 1309 [Sanfilippo1998a] 1310 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1311 mailing-list, Mon Dec 14 1998, 1312 . 1314 [Sanfilippo1998b] 1315 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1316 1998, . 1318 [Sanfilippo1999] 1319 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1320 list, 1999, 1321 . 1323 [Silbersack2005] 1324 Silbersack, M., "Improving TCP/IP security through 1325 randomization without sacrificing interoperability", 1326 EuroBSDCon 2005 Conference, 2005, 1327 . 1330 [Zalewski2003] 1331 Zalewski, M., "A new TCP/IP blind data injection 1332 technique?", 2003, 1333 . 1335 [Klein2007] 1336 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 1337 Predictable IP ID Vulnerability", 2007, 1338 . 1341 [Gont2011] 1342 Gont, F., "Hacking IPv6 Networks (training course)", Hack 1343 In Paris 2011 Conference Paris, France, June 2011. 1345 [RedHat2011] 1346 RedHat, , "RedHat Security Advisory RHSA-2011:1465-1: 1347 Important: kernel security and bug fix update", 2011, 1348 . 1350 [Ubuntu2011] 1351 Ubuntu, , "Ubuntu: USN-1253-1: Linux kernel 1352 vulnerabilities", 2011, 1353 . 1355 [SUSE2011] 1356 SUSE, , "SUSE Security Announcement: Linux kernel security 1357 update (SUSE-SA:2011:046)", 2011, 1358 . 1361 [Gont2012] 1362 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 1363 Conference Ottawa, Canada. May 11-12, 2012, May 2012. 1365 [I-D.ietf-6man-predictable-fragment-id-08] 1366 Gont, F., "Security Implications of Predictable Fragment 1367 Identification Values", draft-ietf-6man-predictable- 1368 fragment-id-08 (work in progress), June 2015. 1370 [I-D.ietf-6man-default-iids] 1371 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1372 "Recommendation on Stable IPv6 Interface Identifiers", 1373 draft-ietf-6man-default-iids-09 (work in progress), 1374 January 2016. 1376 [I-D.ietf-6man-ipv6-address-generation-privacy] 1377 Cooper, A., Gont, F., and D. Thaler, "Privacy 1378 Considerations for IPv6 Address Generation Mechanisms", 1379 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 1380 in progress), September 2015. 1382 [I-D.ietf-opsec-ipv6-host-scanning] 1383 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1384 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 1385 progress), August 2015. 1387 [FIPS-SHS] 1388 FIPS, , "Secure Hash Standard (SHS)", Federal Information 1389 Processing Standards Publication 180-4, March 2012, 1390 . 1393 Authors' Addresses 1394 Fernando Gont 1395 SI6 Networks / UTN-FRH 1396 Evaristo Carriego 2644 1397 Haedo, Provincia de Buenos Aires 1706 1398 Argentina 1400 Phone: +54 11 4650 8472 1401 Email: fgont@si6networks.com 1402 URI: http://www.si6networks.com 1404 Ivan Arce 1405 Fundacion Dr. Manuel Sadosky 1406 Av. Cordoba 744 Piso 5 Oficina I 1407 Ciudad Autonoma de Buenos Aires, Buenos Aires C1054AAT 1408 Argentina 1410 Phone: +54 11 4328 5164 1411 Email: stic@fundacionsadosky.org.ar 1412 URI: http://www.fundacionsadosky.org.ar