idnits 2.17.1 draft-irtf-pearg-numeric-ids-history-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 2073 (Obsoleted by RFC 2374) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) == Outdated reference: A later version (-05) exists of draft-eddy-rfc793bis-04 == Outdated reference: A later version (-11) exists of draft-gont-numeric-ids-sec-considerations-05 == Outdated reference: A later version (-12) exists of draft-ietf-6man-rfc4941bis-11 == Outdated reference: A later version (-08) exists of draft-ietf-ntp-port-randomization-06 == Outdated reference: A later version (-12) exists of draft-irtf-pearg-numeric-ids-generation-03 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force (IRTF) F. Gont 3 Internet-Draft SI6 Networks 4 Intended status: Informational I. Arce 5 Expires: April 24, 2021 Quarkslab 6 October 21, 2020 8 Unfortunate History of Transient Numeric Identifiers 9 draft-irtf-pearg-numeric-ids-history-03 11 Abstract 13 This document analyzes the timeline of the specification and 14 implementation of different types of "transient numeric identifiers" 15 used in IETF protocols, and how the security and privacy properties 16 of such protocols have been affected as a result of it. It provides 17 empirical evidence that advice in this area is warranted. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 24, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 4 54 5. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 7 55 6. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 9 56 7. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . . . 12 57 8. Transport Protocol Ephemeral Port Numbers . . . . . . . . . . 12 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 60 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 63 12.2. Informative References . . . . . . . . . . . . . . . . . 17 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 66 1. Introduction 68 Networking protocols employ a variety of transient numeric 69 identifiers for different protocol objects, ranging from DNS 70 Transaction IDs (TxIDs) to transport protocol ephemeral port numbers 71 or IPv6 Interface Identifiers (IIDs). These identifiers typically 72 have specific interoperability requirements (e.g. uniqueness during a 73 specified period of time), and an associated modes when such 74 properties are not met [I-D.irtf-pearg-numeric-ids-generation]. 76 For more than 30 years, a large number of implementations of the TCP/ 77 IP protocol suite have been subject to a variety of attacks, with 78 effects ranging from Denial of Service (DoS) or data injection, to 79 information leakages that could be exploited for pervasive monitoring 80 [RFC7258]. The root cause of these issues has been, in many cases, 81 poor selection of numeric identifiers, usually as a result of 82 insufficient or misleading specifications. 84 For example, implementations have been subject to security or privacy 85 issues resulting from: 87 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. 88 [Morris1985]) 90 o Predictable transport protocol ephemeral port numbers (see e.g. 91 [RFC6056] and [Silbersack2005]) 93 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 94 [RFC5722], [RFC6274], and [RFC7739]) 96 o Predictable IPv6 IIDs (see e.g. [RFC7721] and [RFC7707]) 98 o Predictable DNS TxIDs [RFC1035] 100 Recent history indicates that when new protocols are standardized or 101 implemented, the security and privacy properties of the associated 102 transient numeric identifiers tend to be overlooked, and 103 inappropriate algorithms to generate such identifiers (i.e. with 104 negative security or privacy properties) are either suggested in the 105 specification or selected by implementers. 107 This document contains a non-exhaustive timeline of the specification 108 and vulnerability disclosures related to some sample transient 109 numeric identifiers, including other work that has led to advances in 110 this area. This analysis indicates that: 112 o Vulnerabilities associated with the inappropriate generation of 113 transient numeric identifiers have affected protocol 114 implementations for an extremely long period of time. 116 o Such vulnerabilities, even when addressed for a given protocol 117 version, were later reintroduced in new versions or new 118 implementations of the same protocol. 120 o Standardization efforts that discuss and provide advice in this 121 area can have a positive effect on protocol specifications and 122 protocol implementations. 124 While it is generally possible to identify an algorithm that can 125 satisfy the interoperability requirements for a given numeric 126 identifier, this document provides empirical evidence that doing so 127 without negatively affecting the security or privacy properties of 128 the aforementioned protocols is non-trivial. Other related documents 129 ([I-D.irtf-pearg-numeric-ids-generation] and 130 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this 131 area, as motivated by the present document. 133 2. Terminology 135 Transient Numeric Identifier: 136 A data object in a protocol specification that can be used to 137 definitely distinguish a protocol object (a datagram, network 138 interface, transport protocol endpoint, session, etc) from all 139 other objects of the same type, in a given context. Transient 140 numeric identifiers are usually defined as a series of bits, and 141 represented using integer values. These identifiers are typically 142 dynamically selected, as opposed to statically-assigned numeric 143 identifiers (see e.g. [IANA-PROT]). We note that different 144 identifiers may have additional requirements or properties 145 depending on their specific use in a protocol. We use the term 146 "transient numeric identifier" (or simply "numeric identifier" or 147 "identifier" as short forms) as a generic term to refer to any 148 data object in a protocol specification that satisfies the 149 identification property stated above. 151 The terms "constant IID", "stable IID", and "temporary IID" are to be 152 interpreted as defined in [RFC7721]. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 3. Threat Model 160 Throughout this document, we assume an attacker does not have 161 physical or logical access to the device(s) being attacked. We 162 assume the attacker can simply send any traffic to the target 163 device(s), to e.g. sample identifiers employed by such device(s). 165 4. IPv4/IPv6 Identification 167 This section presents the timeline of the Identification field 168 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). 169 The reason for presenting both cases in the same section is to make 170 it evident that while the Identification value serves the same 171 purpose in both IPv4 and IPv6, the work and research done for the 172 IPv4 case did not affect IPv6 specifications or implementations. 174 The IPv4 Identification value is specified in [RFC0791], which 175 specifies the interoperability requirements for the Identification 176 field: the sender must choose the Identification field to be unique 177 for a given source address, destination address, and protocol, for 178 the time the datagram (or any fragment of it) could be alive in the 179 internet. It suggests that a node may keep "a table of Identifiers, 180 one entry for each destination it has communicated with in the last 181 maximum packet lifetime for the internet", and suggests that "since 182 the Identifier field allows 65,536 different values, hosts may be 183 able to simply use unique identifiers independent of destination". 184 The above has been interpreted numerous times as a suggestion to 185 employ per-destination or global counters for the generation of 186 Identification values. While [RFC0791] does not suggest any flawed 187 algorithm for the generation of Identification values, the 188 specification omits a discussion of the security and privacy 189 implications of predictable Identification values. This has resulted 190 in many IPv4 implementations generating predictable fragment 191 Identification values by means of a global counter, at least at some 192 point in time. 194 The IPv6 Identification is specified in [RFC2460]. It serves the 195 same purpose as its IPv4 counterpart, with the only difference 196 residing in the length of the corresponding field, and that while the 197 IPv4 Identification field is part of the base IPv4 header, in the 198 IPv6 case it is part of the Fragment header (which may or may not be 199 present in an IPv6 packet). [RFC2460] states, in Section 4.5, that 200 the Identification must be different than that of any other 201 fragmented packet sent recently (within the maximum likely lifetime 202 of a packet) with the same Source Address and Destination Address. 203 Subsequently, it notes that this requirement can be met by means of a 204 wrap-around 32-bit counter that is incremented each time a packet 205 must be fragmented, and that it is an implementation choice whether 206 to use a global or a per-destination counter. Thus, the 207 implementation of the IPv6 Identification is similar to that of the 208 IPv4 case, with the only difference that in the IPv6 case the 209 suggestions to use simple counters is more explicit. 211 September 1981: 212 [RFC0791] specifies the interoperability requirements for IPv4 213 Identification value, but does not specify any requirements in the 214 area of security and privacy. 216 December 1998: 217 [Sanfilippo1998a] finds that predictable IPv4 Identification 218 values (generated by most popular implementations) can be 219 leveraged to count the number of packets sent by a target node. 220 [Sanfilippo1998b] explains how to leverage the same vulnerability 221 to implement a port-scanning technique known as dumb/idle scan. A 222 tool that implements this attack is publicly released. 224 December 1998: 225 [RFC2460] suggests that a global counter be used to generate the 226 IPv6 Identification value. 228 November 1999: 229 [Sanfilippo1999] discusses how to leverage predictable IPv4 230 Identification to uncover the rules of a number of firewalls. 232 November 1999: 233 [Bellovin2002] explains how the IPv4 Identification field can be 234 exploited to count the number of systems behind a NAT. 236 September 2002: 238 [Fyodor2002] explains how to implement a stealth port-scanning 239 technique by leveraging nodes that employ predictable IPv4 240 Identification values. 242 December 2003: 243 [Zalewski2003] explains a technique to perform TCP data injection 244 attack based on predictable IPv4 identification values which 245 requires less effort than TCP injection attacks performed with 246 bare TCP packets. 248 November 2005: 249 [Silbersack2005] discusses shortcoming in a number of techniques 250 to mitigate predictable IPv4 Identification values. 252 October 2007: 253 [Klein2007] describes a weakness in the pseudo random number 254 generator (PRNG) in use for the generation of the IP 255 Identification by a number of operating systems. 257 June 2011: 258 [Gont2011] describes how to perform idle scan attacks in IPv6. 260 November 2011: 261 Linux mitigates predictable IPv6 Identification values 262 [RedHat2011] [SUSE2011] [Ubuntu2011]. 264 December 2011: 265 [draft-gont-6man-predictable-fragment-id-00] describes the 266 security implications of predictable IPv6 Identification values, 267 and possible mitigations. This document is published on the 268 Standards Track, meaning to formally update [RFC2460], to 269 introduce security and privacy requirements on IPv6 Identification 270 values. 272 May 2012: 273 [Gont2012] notes that some major IPv6 implementations still employ 274 predictable IPv6 Identification values. 276 March 2013: 277 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but 278 changes the track to "BCP" (while still formally updating 279 [RFC2460]), publishing the resulting document as 280 [draft-ietf-6man-predictable-fragment-id-00]. 282 June 2013: 283 A patch that implements IPv6-based idle-scan in nmap is submitted 284 [Morbitzer2013]. 286 December 2014: 287 The 6man WG changes the status of 288 [draft-ietf-6man-predictable-fragment-id-01] to "Informational" 289 and publishes it as [draft-ietf-6man-predictable-fragment-id-02]. 290 As a result, it no longer formally updates [RFC2460]. 292 June 2015: 293 [draft-ietf-6man-predictable-fragment-id-08] notes that some 294 popular host and router implementations still employ predictable 295 IPv6 Identification values. 297 February 2016: 298 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) 299 analyzes the security and privacy implications of predictable IPv6 300 Identification values, and provides guidance for selecting an 301 algorithm to generate such values. However, being published on 302 the Informational track, it does not formally update [RFC2460]. 304 June 2016: 305 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the 306 suggestion from RFC2460 to employ a global counter for the 307 generation of IPv6 Identification values, but does not specify any 308 security and privacy requirements for the IPv6 Identification 309 value. 311 July 2017: 312 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], 313 obsoleting [RFC2460], and pointing to [RFC7739] for sample 314 algorithms for the generation of IPv6 Fragment Identification 315 values. 317 June 2019: 318 [IPID-DEV] notes that the IPv6 ID generators of two popular 319 operating systems are flawed. 321 5. TCP Initial Sequence Numbers (ISNs) 323 [RFC0793] suggests that the choice of the ISN of a connection is not 324 arbitrary, but aims to reduce the chances of a stale segment from 325 being accepted by a new incarnation of a previous connection. 326 [RFC0793] suggests the use of a global 32-bit ISN generator that is 327 incremented by 1 roughly every 4 microseconds. However, as a matter 328 of fact, protection against stale segments from a previous 329 incarnation of the connection is enforced by preventing the creation 330 of a new incarnation of a previous connection before 2*MSL have 331 passed since a segment corresponding to the old incarnation was last 332 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This 333 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept 334 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are 335 monotonically increasing across connections, many stacks (e.g., 336 4.2BSD-derived) use the ISN of an incoming SYN segment to perform 337 "heuristics" that enable the creation of a new incarnation of a 338 connection while the previous incarnation is still in the TIME-WAIT 339 state (see p. 945 of [Wright1994]). This avoids an interoperability 340 problem that may arise when a node establishes connections to a 341 specific TCP end-point at a high rate [Silbersack2005]. 343 The interoperability requirements for TCP ISNs are probably not 344 clearly spelled out as one would expect. Furthermore, the suggestion 345 of employing a global counter in [RFC0793] results in negative 346 security and privacy properties. 348 September 1981: 349 [RFC0793], suggests the use of a global 32-bit ISN generator, 350 whose lower bit is incremented roughly every 4 microseconds. 351 However, such an ISN generator makes it trivial to predict the ISN 352 that a TCP will use for new connections, thus allowing a variety 353 of attacks against TCP. 355 February 1985: 356 [Morris1985] was the first to describe how to exploit predictable 357 TCP ISNs for forging TCP connections that could then be leveraged 358 for trust relationship exploitation. 360 April 1989: 361 [Bellovin1989] discussed the security considerations for 362 predictable ISNs (along with a range of other protocol-based 363 vulnerabilities). 365 February 1995: 366 [Shimomura1995] reported a real-world exploitation of the attack 367 described in 1985 (ten years before) in [Morris1985]. 369 May 1996: 370 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 371 to address predictable TCP ISNs. The same concept specified in 372 this document for TCP ISNs was later proposed for TCP ephemeral 373 ports [RFC6056], TCP Timestamps, and eventually even IPv6 374 Interface Identifiers [RFC7217]. 376 March 2001: 377 [Zalewski2001] provides a detailed analysis of statistical 378 weaknesses in some ISN generators, and includes a survey of the 379 algorithms in use by popular TCP implementations. 381 May 2001: 383 Vulnerability advisories [CERT2001] [USCERT2001] are released 384 regarding statistical weaknesses in some ISN generators, affecting 385 popular TCP/IP implementations. 387 March 2002: 388 [Zalewski2002] updates and complements [Zalewski2001]. It 389 concludes that "while some vendors [...] reacted promptly and 390 tested their solutions properly, many still either ignored the 391 issue and never evaluated their implementations, or implemented a 392 flawed solution that apparently was not tested using a known 393 approach" [Zalewski2002]. 395 February 2012: 396 [RFC6528], after 27 years of Morris' original work [Morris1985], 397 formally updates [RFC0793] to mitigate predictable TCP ISNs. 399 August 2014: 400 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 401 protocol specification, incorporates the algorithm specified in 402 [RFC6528] as the recommended algorithm for TCP ISN generation. 404 6. IPv6 Interface Identifiers (IIDs) 406 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC 407 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section 408 focuses on Interface Identifiers resulting from SLAAC. 410 The Interface Identifier of stable (traditional) IPv6 addresses 411 resulting from SLAAC have traditionally resulted in the underlying 412 link-layer address being embedded in the IID.At the time, employing 413 the underlying link-layer address for the IID was seen as a 414 convenient way to obtain a unique address. However, recent awareness 415 about the security and privacy properties of this approach [RFC7707] 416 [RFC7721] has led to the replacement of this flawed scheme with an 417 alternative one that mitigates its negative security and privacy 418 properties [RFC7217] [RFC8064]. 420 January 1997: 421 [RFC2073] specifies the syntax of IPv6 global addresses (referred 422 to as "An IPv6 Provider-Based Unicast Address Format" at the 423 time), consistent with the IPv6 addressing architecture specified 424 in [RFC1884]. Hosts are recommended to "generate addresses using 425 link-specific addresses as Interface ID such as 48 bit IEEE-802 426 MAC addresses". 428 July 1998: 429 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address 430 Format" (obsoleting [RFC2373]) changing the size of the Interface 431 ID to 64 bits, and specifies that that IIDs must be constructed in 432 IEEE EUI-64 format. How such identifiers are constructed becomes 433 specified in the appropriate "IPv6 over " specification such 434 as "IPv6 over Ethernet". 436 January 2001: 437 [RFC3041] recognizes the problem of network activity correlation, 438 and specifies temporary addresses. Temporary addresses are to be 439 used along with stable addresses. 441 August 2003: 442 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure 443 historic. The syntax and recommendations for the traditional 444 stable IIDs remain unchanged, though. 446 February 2006: 447 [RFC4291] is published as the latest "IP Version 6 Addressing 448 Architecture", requiring the IIDs of the traditional (stable) 449 autoconfigured addresses to employ the Modified EUI-64 format. 450 The details of constructing such interface identifiers are defined 451 in the appropriate "IPv6 over " specifications. 453 March 2008: 454 [RFC5157] provides hints regarding how patterns in IPv6 addresses 455 could be leveraged for the purpose of address scanning. 457 December 2011: 458 [draft-gont-6man-stable-privacy-addresses-00] notes that the 459 traditional scheme for generating stable addresses allows for 460 address scanning, and also does not prevent active node tracking. 461 It also specifies an alternative algorithm meant to replace IIDs 462 based on Modified EUI-64 format identifiers. 464 November 2012: 465 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a 466 working group item (as 467 [draft-ietf-6man-stable-privacy-addresses-00]). However, the 468 specified algorithm no longer formally replaces the Modified 469 EUI-64 format identifiers. 471 February 2013: 472 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages 473 IPv6 address patterns is released [Gont2013]. 475 July 2013: 476 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on 477 the security and privacy properties of all known algorithms for 478 generating IPv6 IIDs. 480 January 2014: 481 The 6man WG publishes [draft-ietf-6man-default-iids-00] 482 ("Recommendation on Stable IPv6 Interface Identifiers"), 483 recommending [I-D.ietf-6man-stable-privacy-addresses] for the 484 generation of stable addresses. 486 April 2014: 487 [RFC7217] is published, specifying "A Method for Generating 488 Semantically Opaque Interface Identifiers with IPv6 Stateless 489 Address Autoconfiguration (SLAAC)" as an alternative to (but *not* 490 replacement of) Modified EUI-64 format IIDs. 492 March 2016: 493 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning] and later 494 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network 495 Reconnaissance in IPv6 Networks", is published. 497 March 2016: 498 [RFC7721] (formerly 499 [I-D.cooper-6man-ipv6-address-generation-privacy] and later 500 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security 501 and Privacy Considerations for IPv6 Address Generation 502 Mechanisms", is published. 504 May 2016: 505 [draft-gont-6man-non-stable-iids-00] is published, with the goal 506 of specifying requirements for non-stable addresses, and updating 507 [RFC4941] such that use of only temporary addresses is allowed. 509 May 2016: 510 [draft-gont-6man-address-usage-recommendations-00] is published, 511 providing an analysis of how different aspects on an address (from 512 stability to usage mode) affect their corresponding security and 513 privacy properties, and meaning to eventually provide advice in 514 this area. 516 February 2017: 517 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6 518 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), 519 with requirements for stable addresses and a recommendation to 520 employ [RFC7217] for the generation of stable addresses. It 521 formally updated a large number of RFCs. 523 March 2018: 524 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the 525 6man WG), to address flaws in [RFC4941] by revising it (as an 526 alternative to the [draft-gont-6man-non-stable-iids-00] effort, 527 published in March 2016). 529 July 2018: 530 [draft-ietf-6man-rfc4941bis-00] is adopted (as 531 [draft-fgont-6man-rfc4941bis-00]) as a WG item of the 6man WG. 533 March 2020: 534 [I-D.ietf-6man-rfc4941bis] passes WGLC. 536 7. NTP Reference IDs (REFIDs) 538 NTP [RFC5905] Reference IDs are employed to avoid degree-one timing 539 loops in scenarios where two NTP peers are (mutually) the time source 540 of each other. 542 June 2010: 543 [RFC5905], "Network Time Protocol Version 4: Protocol and 544 Algorithms Specification" is published. It specifies that for NTP 545 peers with stratum higher than 1 the REFID embeds the IPv4 Address 546 of the time source or an MD5 hash of the IPv6 address of the time 547 source. 549 July 2016: 550 [draft-stenn-ntp-not-you-refid-00] is published, describing the 551 information leakage produced via de NTP REFID. It proposes that 552 NTP returns a special REFID when a packet employs an IP Source 553 Address that is not believed to be a current NTP peer, but 554 otherwise generates and returns the traditional REFID. It is 555 subsequently adopted by the NTP WG as 556 [I-D.ietf-ntp-refid-updates]. 558 April 2019: 559 [Gont-NTP] notes that the proposed fix specified in 560 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub- 561 optimal. 563 8. Transport Protocol Ephemeral Port Numbers 565 Most (if not all) transport protocols employ "port numbers" to 566 demultiplex packets to the corresponding transport protocol 567 instances. 569 August 1980: 570 [RFC0768] notes that the UDP source port is optional and 571 identifies the port of the sending process. It does not specify 572 interoperability requirements for source port selection, nor does 573 it suggest possible ways to select port numbers. Most popular 574 implementations end up selecting source ports from a system-wide 575 global counter. 577 September 1981: 578 [RFC0793] (the TCP specification) essentially describes the use of 579 port numbers, and specifies that port numbers should result in a 580 unique socket pair (local address, local port, remote address, 581 remote port). How ephemeral ports (i.e. port numbers for "active 582 opens") are selected, and the port range from which they are 583 selected, are left unspecified. 585 January 2009: 586 [RFC5452] mandates the use of port randomization for DNS 587 resolvers, and mandates that implementations must randomize ports 588 from the range (53 or 1024, and above) or the largest possible 589 port range. It does not recommend possible algorithms for port 590 randomization, although the document specifically targets DNS 591 resolvers, for which a simple port randomization suffices (e.g. 592 Algorithm 1 of [RFC6056]). This document led to the 593 implementation of port randomization in the DNS resolver 594 themselves, rather than in the underlying transport-protocols. 596 January 2011: 597 [RFC6056] notes that many TCP and UDP implementations result in 598 predictable port numbers, and also notes that many implementations 599 select port numbers from a small portion of the whole port number 600 space. It recommends the implementation and use of ephemeral port 601 randomization, proposes a number of possible algorithms for port 602 randomization, and also recommends to randomize port numbers over 603 the range 1024-65535. 605 March 2016: 606 [NIST-NTP] reports a non-normal distribution of the ephemeral port 607 numbers employed by the NTP clients of an Internet Time Service. 609 April 2019: 610 [I-D.gont-ntp-port-randomization] notes that some NTP 611 implementations employ the NTP service port (123) as the local 612 port for non-symmetric modes, and aims to update the NTP 613 specification to recommend port randomization in such cases, in 614 line with [RFC6056]. The proposal experiences some push-back in 615 the relevant working group (NTP WG) [NTP-PORTR], but is finally 616 adopted as a working group item as 617 [I-D.ietf-ntp-port-randomization]. 619 9. IANA Considerations 621 There are no IANA registries within this document. The RFC-Editor 622 can remove this section before publication of this document as an 623 RFC. 625 10. Security Considerations 627 This document analyzes the timeline of some sample IETF protocol 628 "numeric identifiers", and how the security and privacy properties of 629 such protocols has been affected as a result of it. It provides 630 concrete evidence that advice in this area is warranted. 631 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol 632 specifications to do a warranted analysis of the interoperability 633 properties of the transient numeric identifiers they specify, and to 634 recommend possible algorithms for their generation, such that 635 negative security and privacy properties are avoided. 636 [I-D.irtf-pearg-numeric-ids-generation] analyzes categorizes 637 transient numeric identifiers based on their interoperability 638 requirements and their associated failure modes, and recommends 639 possible algorithms to that can comply with the associated 640 requirements without resulting in negative security and privacy 641 properties. 643 11. Acknowledgements 645 The authors would like to thank (in alphabetical order) Dave Crocker, 646 Christian Huitema, and Joe Touch, and Christopher Wood, for providing 647 valuable comments on earlier versions of this document. 649 The authors would like to thank (in alphabetical order) Steven 650 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 651 providing valuable comments on [I-D.gont-predictable-numeric-ids], on 652 which this document is based. 654 Section 5 of this document borrows text from [RFC6528], authored by 655 Fernando Gont and Steven Bellovin. 657 The authors would like to thank Christopher Wood for his guidance 658 during the publication process of this document. 660 The authors would like to thank Diego Armando Maradona for his magic 661 and inspiration. 663 12. References 665 12.1. Normative References 667 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 668 DOI 10.17487/RFC0768, August 1980, 669 . 671 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 672 DOI 10.17487/RFC0791, September 1981, 673 . 675 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 676 RFC 793, DOI 10.17487/RFC0793, September 1981, 677 . 679 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 680 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 681 1992, . 683 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 684 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 685 December 1995, . 687 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. 688 Postel, "An IPv6 Provider-Based Unicast Address Format", 689 RFC 2073, DOI 10.17487/RFC2073, January 1997, 690 . 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, 694 DOI 10.17487/RFC2119, March 1997, 695 . 697 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 698 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 699 . 701 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 702 Aggregatable Global Unicast Address Format", RFC 2374, 703 DOI 10.17487/RFC2374, July 1998, 704 . 706 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 707 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 708 December 1998, . 710 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 711 Stateless Address Autoconfiguration in IPv6", RFC 3041, 712 DOI 10.17487/RFC3041, January 2001, 713 . 715 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 716 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 717 August 2003, . 719 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 720 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 721 2006, . 723 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 724 Address Autoconfiguration", RFC 4862, 725 DOI 10.17487/RFC4862, September 2007, 726 . 728 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 729 Extensions for Stateless Address Autoconfiguration in 730 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 731 . 733 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 734 Resilient against Forged Answers", RFC 5452, 735 DOI 10.17487/RFC5452, January 2009, 736 . 738 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 739 RFC 5722, DOI 10.17487/RFC5722, December 2009, 740 . 742 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 743 Protocol Port Randomization", BCP 156, RFC 6056, 744 DOI 10.17487/RFC6056, January 2011, 745 . 747 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 748 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 749 2012, . 751 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 752 Interface Identifiers with IPv6 Stateless Address 753 Autoconfiguration (SLAAC)", RFC 7217, 754 DOI 10.17487/RFC7217, April 2014, 755 . 757 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 758 (IPv6) Specification", STD 86, RFC 8200, 759 DOI 10.17487/RFC8200, July 2017, 760 . 762 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 763 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 764 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 765 RFC 8415, DOI 10.17487/RFC8415, November 2018, 766 . 768 12.2. Informative References 770 [Bellovin1989] 771 Bellovin, S., "Security Problems in the TCP/IP Protocol 772 Suite", Computer Communications Review, vol. 19, no. 2, 773 pp. 32-48, 1989, 774 . 776 [Bellovin2002] 777 Bellovin, S., "A Technique for Counting NATted Hosts", 778 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 780 [CERT2001] 781 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 782 TCP/IP Initial Sequence Numbers", 2001, 783 . 785 [draft-fgont-6man-rfc4941bis-00] 786 Gont, F., Krishnan, S., Narten, T., and R. Draves, 787 "Privacy Extensions for Stateless Address 788 Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00 789 (work in progress), March 2018. 791 [draft-gont-6man-address-usage-recommendations-00] 792 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", 793 draft-gont-6man-address-usage-recommendations-00 (work in 794 progress), May 2016. 796 [draft-gont-6man-non-stable-iids-00] 797 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 798 Interface Identifiers", draft-gont-6man-non-stable-iids-00 799 (work in progress), May 2016. 801 [draft-gont-6man-predictable-fragment-id-00] 802 Gont, F., "Security Implications of Predictable Fragment 803 Identification Values", draft-gont-6man-predictable- 804 fragment-id-00 (work in progress), December 2011. 806 [draft-gont-6man-stable-privacy-addresses-00] 807 Gont, F., "A method for Generating Stable Privacy-Enhanced 808 Addresses with IPv6 Stateless Address Autoconfiguration 809 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00 810 (work in progress), December 2011. 812 [draft-ietf-6man-default-iids-00] 813 Gont, F., Cooper, A., Thaler, D., and W. Liu, 814 "Recommendation on Stable IPv6 Interface Identifiers", 815 draft-ietf-6man-default-iids-00 (work in progress), July 816 2014. 818 [draft-ietf-6man-predictable-fragment-id-00] 819 Gont, F., "Security Implications of Predictable Fragment 820 Identification Values", draft-ietf-6man-predictable- 821 fragment-id-00 (work in progress), March 2013. 823 [draft-ietf-6man-predictable-fragment-id-01] 824 Gont, F., "Security Implications of Predictable Fragment 825 Identification Values", draft-ietf-6man-predictable- 826 fragment-id-01 (work in progress), April 2014. 828 [draft-ietf-6man-predictable-fragment-id-02] 829 Gont, F., "Security Implications of Predictable Fragment 830 Identification Values", draft-ietf-6man-predictable- 831 fragment-id-02 (work in progress), December 2014. 833 [draft-ietf-6man-predictable-fragment-id-08] 834 Gont, F., "Security Implications of Predictable Fragment 835 Identification Values", draft-ietf-6man-predictable- 836 fragment-id-08 (work in progress), June 2015. 838 [draft-ietf-6man-rfc4941bis-00] 839 Gont, F., Krishnan, S., Narten, T., and R. Draves, 840 "Privacy Extensions for Stateless Address 841 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00 842 (work in progress), July 2018. 844 [draft-ietf-6man-stable-privacy-addresses-00] 845 Gont, F., "A method for Generating Stable Privacy-Enhanced 846 Addresses with IPv6 Stateless Address Autoconfiguration 847 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 848 (work in progress), May 2012. 850 [draft-ietf-ntp-refid-updates-00] 851 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 852 REFID", draft-ietf-ntp-refid-updates-00 (work in 853 progress), November 2016. 855 [draft-stenn-ntp-not-you-refid-00] 856 Goldberg, S. and S. KrishnansTENN, "Network Time Protocol 857 Not You REFID", draft-stenn-ntp-not-you-refid-00 (work in 858 progress), July 2016. 860 [Fyodor2002] 861 Fyodor, "Idle scanning and related IP ID games", 2002, 862 . 864 [Gont-NTP] 865 Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- 866 05", Post to the NTP WG mailing list Message-ID: 867 , 868 April 2019, . 871 [Gont2011] 872 Gont, F., "Hacking IPv6 Networks (training course)", Hack 873 In Paris 2011 Conference Paris, France, June 2011. 875 [Gont2012] 876 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 877 Conference Ottawa, Canada. May 11-12, 2012, May 2012. 879 [Gont2013] 880 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit 881 (help wanted!)", Message posted to the IPv6 Hackers 882 mailing-list Message-ID: 883 <51184548.3030105@si6networks.com>, 1995, 884 . 887 [I-D.cooper-6man-ipv6-address-generation-privacy] 888 Cooper, A., Gont, F., and D. Thaler, "Privacy 889 Considerations for IPv6 Address Generation Mechanisms", 890 draft-cooper-6man-ipv6-address-generation-privacy-00 (work 891 in progress), July 2013. 893 [I-D.eddy-rfc793bis-04] 894 Eddy, W., "Transmission Control Protocol Specification", 895 draft-eddy-rfc793bis-04 (work in progress), August 2014. 897 [I-D.gont-6man-predictable-fragment-id] 898 Gont, F., "Security Implications of Predictable Fragment 899 Identification Values", draft-gont-6man-predictable- 900 fragment-id-03 (work in progress), January 2013. 902 [I-D.gont-6man-stable-privacy-addresses] 903 Gont, F., "A method for Generating Stable Privacy-Enhanced 904 Addresses with IPv6 Stateless Address Autoconfiguration 905 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01 906 (work in progress), March 2012. 908 [I-D.gont-ntp-port-randomization] 909 Gont, F. and G. Gont, "Port Randomization in the Network 910 Time Protocol Version 4", draft-gont-ntp-port- 911 randomization-04 (work in progress), August 2019. 913 [I-D.gont-numeric-ids-sec-considerations] 914 Gont, F. and I. Arce, "Security Considerations for 915 Transient Numeric Identifiers Employed in Network 916 Protocols", draft-gont-numeric-ids-sec-considerations-05 917 (work in progress), July 2020. 919 [I-D.gont-opsec-ipv6-host-scanning] 920 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 921 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in 922 progress), October 2012. 924 [I-D.gont-predictable-numeric-ids] 925 Gont, F. and I. Arce, "Security and Privacy Implications 926 of Numeric Identifiers Employed in Network Protocols", 927 draft-gont-predictable-numeric-ids-03 (work in progress), 928 March 2019. 930 [I-D.ietf-6man-default-iids] 931 Gont, F., Cooper, A., Thaler, D., and S. LIU, 932 "Recommendation on Stable IPv6 Interface Identifiers", 933 draft-ietf-6man-default-iids-16 (work in progress), 934 September 2016. 936 [I-D.ietf-6man-ipv6-address-generation-privacy] 937 Cooper, A., Gont, F., and D. Thaler, "Privacy 938 Considerations for IPv6 Address Generation Mechanisms", 939 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 940 in progress), September 2015. 942 [I-D.ietf-6man-predictable-fragment-id] 943 Gont, F., "Security Implications of Predictable Fragment 944 Identification Values", draft-ietf-6man-predictable- 945 fragment-id-10 (work in progress), October 2015. 947 [I-D.ietf-6man-rfc2460bis] 948 Deering, S. and R. Hinden, "Internet Protocol, Version 6 949 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 950 in progress), May 2017. 952 [I-D.ietf-6man-rfc4941bis] 953 Gont, F., Krishnan, S., Narten, T., and R. Draves, 954 "Temporary Address Extensions for Stateless Address 955 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-11 956 (work in progress), September 2020. 958 [I-D.ietf-6man-stable-privacy-addresses] 959 Gont, F., "A Method for Generating Semantically Opaque 960 Interface Identifiers with IPv6 Stateless Address 961 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 962 privacy-addresses-17 (work in progress), January 2014. 964 [I-D.ietf-ntp-port-randomization] 965 Gont, F., Gont, G., and M. Lichvar, "Port Randomization in 966 the Network Time Protocol Version 4", draft-ietf-ntp-port- 967 randomization-06 (work in progress), September 2020. 969 [I-D.ietf-ntp-refid-updates] 970 Stenn, H. and S. Goldberg, "Network Time Protocol REFID 971 Updates", draft-ietf-ntp-refid-updates-05 (work in 972 progress), March 2019. 974 [I-D.ietf-opsec-ipv6-host-scanning] 975 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 976 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 977 progress), August 2015. 979 [I-D.irtf-pearg-numeric-ids-generation] 980 Gont, F. and I. Arce, "On the Generation of Transient 981 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 982 generation-03 (work in progress), September 2020. 984 [IANA-PROT] 985 IANA, "Protocol Registries", 986 . 988 [IPID-DEV] 989 Klein, A. and B. Pinkas, "From IP ID to Device ID and 990 KASLR Bypass (Extended Version)", June 2019, 991 . 993 [IPv6-Toolkit] 994 SI6 Networks, "SI6 Networks' IPv6 Toolkit", 995 . 997 [Klein2007] 998 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 999 Predictable IP ID Vulnerability", 2007, 1000 . 1003 [Morbitzer2013] 1004 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message 1005 posted to the nmap-dev mailing-list, 2013, 1006 . 1008 [Morris1985] 1009 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1010 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1011 NJ, 1985, 1012 . 1014 [NIST-NTP] 1015 Sherman, J. and J. Levine, "Usage Analysis of the NIST 1016 Internet Time Service", Journal of Research of the 1017 National Institute of Standards and Technology Volume 121, 1018 March 2016, . 1020 [NTP-PORTR] 1021 Gont, F., "[Ntp] New rev of the NTP port randomization I-D 1022 (Fwd: New Version Notification for draft-gont-ntp-port- 1023 randomization-01.txt)", 2019, 1024 . 1027 [RedHat2011] 1028 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 1029 Important: kernel security and bug fix update", 2011, 1030 . 1032 [RFC1035] Mockapetris, P., "Domain names - implementation and 1033 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1034 November 1987, . 1036 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1037 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1038 . 1040 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1041 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1042 . 1044 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1045 "Network Time Protocol Version 4: Protocol and Algorithms 1046 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1047 . 1049 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1050 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 1051 . 1053 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1054 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1055 2014, . 1057 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1058 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1059 . 1061 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1062 Considerations for IPv6 Address Generation Mechanisms", 1063 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1064 . 1066 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1067 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1068 February 2016, . 1070 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1071 "Recommendation on Stable IPv6 Interface Identifiers", 1072 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1073 . 1075 [Sanfilippo1998a] 1076 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1077 mailing-list, Mon Dec 14 1998, 1078 . 1080 [Sanfilippo1998b] 1081 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1082 1998, . 1084 [Sanfilippo1999] 1085 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1086 list, 1999, 1087 . 1089 [Shimomura1995] 1090 Shimomura, T., "Technical details of the attack described 1091 by Markoff in NYT", Message posted in USENET's 1092 comp.security.misc newsgroup Message-ID: 1093 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1094 . 1096 [Silbersack2005] 1097 Silbersack, M., "Improving TCP/IP security through 1098 randomization without sacrificing interoperability", 1099 EuroBSDCon 2005 Conference, 2005, 1100 . 1103 [SUSE2011] 1104 SUSE, "SUSE Security Announcement: Linux kernel security 1105 update (SUSE-SA:2011:046)", 2011, 1106 . 1109 [Ubuntu2011] 1110 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 1111 vulnerabilities", 2011, 1112 . 1114 [USCERT2001] 1115 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 1116 TCP/IP implementations may use statistically predictable 1117 initial sequence numbers", 2001, 1118 . 1120 [Wright1994] 1121 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1122 The Implementation", Addison-Wesley, 1994. 1124 [Zalewski2001] 1125 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1126 Number Analysis", 2001, 1127 . 1129 [Zalewski2002] 1130 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1131 Number Analysis - One Year Later", 2001, 1132 . 1134 [Zalewski2003] 1135 Zalewski, M., "A new TCP/IP blind data injection 1136 technique?", 2003, 1137 . 1139 Authors' Addresses 1141 Fernando Gont 1142 SI6 Networks 1143 Evaristo Carriego 2644 1144 Haedo, Provincia de Buenos Aires 1706 1145 Argentina 1147 Phone: +54 11 4650 8472 1148 Email: fgont@si6networks.com 1149 URI: https://www.si6networks.com 1151 Ivan Arce 1152 Quarkslab 1154 Email: iarce@quarkslab.com 1155 URI: https://www.quarkslab.com