idnits 2.17.1 draft-irtf-pearg-numeric-ids-history-05.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 date (January 6, 2021) is 1206 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 1883 (Obsoleted by RFC 2460) ** 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-06 == 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-04 -- Obsolete informational reference (is this intentional?): RFC 1948 (ref. 'OpenBSD-TCP-ISN-H') (Obsoleted by RFC 6528) -- Duplicate reference: RFC1948, mentioned in 'RFC1948', was also mentioned in 'OpenBSD-TCP-ISN-H'. -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 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: July 10, 2021 Quarkslab 6 January 6, 2021 8 Unfortunate History of Transient Numeric Identifiers 9 draft-irtf-pearg-numeric-ids-history-05 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 July 10, 2021. 36 Copyright Notice 38 Copyright (c) 2021 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. Issues with the Specification of Transient Numeric 54 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 5 56 6. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 9 57 7. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 11 58 8. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . . . 14 59 9. Transport Protocol Ephemeral Port Numbers . . . . . . . . . . 14 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 61 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 62 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 63 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 64 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 65 13.2. Informative References . . . . . . . . . . . . . . . . . 19 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 68 1. Introduction 70 Networking protocols employ a variety of transient numeric 71 identifiers for different protocol objects, ranging from DNS 72 Transaction IDs (TxIDs) to transport protocol ephemeral port numbers 73 or IPv6 Interface Identifiers (IIDs). These identifiers typically 74 have specific interoperability requirements (e.g. uniqueness during a 75 specified period of time), and an associated modes when such 76 properties are not met [I-D.irtf-pearg-numeric-ids-generation]. 78 For more than 30 years, a large number of implementations of the TCP/ 79 IP protocol suite have been subject to a variety of attacks, with 80 effects ranging from Denial of Service (DoS) or data injection, to 81 information leakages that could be exploited for pervasive monitoring 82 [RFC7258]. The root cause of these issues has been, in many cases, 83 poor selection of transient numeric identifiers, usually as a result 84 of insufficient or misleading specifications. 86 For example, implementations have been subject to security or privacy 87 issues resulting from: 89 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. 90 [Morris1985], [Bellovin1989], and [RFC6528]) 92 o Predictable transport protocol ephemeral port numbers (see e.g. 93 [RFC6056] and [Silbersack2005]) 95 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 96 [Sanfilippo1998a], [RFC6274], and [RFC7739]) 98 o Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and 99 [RFC7217]) 101 o Predictable DNS TxIDs (see e.g. [Schuba1993] and [Klein2007]) 103 These examples indicate that when new protocols are standardized or 104 implemented, the security and privacy properties of the associated 105 transient numeric identifiers tend to be overlooked, and 106 inappropriate algorithms to generate such identifiers (i.e. that 107 negatively affect the security or privacy properties of the protocol) 108 are either suggested in the specification or selected by 109 implementers. 111 This document contains a non-exhaustive timeline of the specification 112 and vulnerability disclosures related to some sample transient 113 numeric identifiers, including other work that has led to advances in 114 this area. This analysis indicates that: 116 o Vulnerabilities associated with the inappropriate generation of 117 transient numeric identifiers have affected protocol 118 implementations for an extremely long period of time. 120 o Such vulnerabilities, even when addressed for a given protocol 121 version, were later reintroduced in new versions or new 122 implementations of the same protocol. 124 o Standardization efforts that discuss and provide advice in this 125 area can have a positive effect on protocol specifications and 126 protocol implementations. 128 While it is generally possible to identify an algorithm that can 129 satisfy the interoperability requirements for a given transient 130 numeric identifier, this document provides empirical evidence that 131 doing so without negatively affecting the security or privacy 132 properties of the aforementioned protocols is non-trivial. Other 133 related documents ([I-D.irtf-pearg-numeric-ids-generation] and 134 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this 135 area, as motivated by the present document. 137 2. Terminology 139 Transient Numeric Identifier: 140 A data object in a protocol specification that can be used to 141 definitely distinguish a protocol object (a datagram, network 142 interface, transport protocol endpoint, session, etc) from all 143 other objects of the same type, in a given context. Transient 144 numeric identifiers are usually defined as a series of bits, and 145 represented using integer values. These identifiers are typically 146 dynamically selected, as opposed to statically-assigned numeric 147 identifiers (see e.g. [IANA-PROT]). We note that different 148 identifiers may have additional requirements or properties 149 depending on their specific use in a protocol. We use the term 150 "transient numeric identifier" (or simply "numeric identifier" or 151 "identifier" as short forms) as a generic term to refer to any 152 data object in a protocol specification that satisfies the 153 identification property stated above. 155 The terms "constant IID", "stable IID", and "temporary IID" are to be 156 interpreted as defined in [RFC7721]. 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, and does 162 not have access to the packets being transferred between the sender 163 and the receiver(s) of the target protocol (if any). However, we 164 assume the attacker can send any traffic to the target device(s), to 165 e.g. sample transient numeric identifiers employed by such device(s). 167 4. Issues with the Specification of Transient Numeric Identifiers 169 While assessing protocol specifications regarding the use of 170 transient numeric identifiers, we have found that most of the issues 171 discussed in this document arise as a result of one of the following 172 conditions: 174 o Protocol specifications that under-specify the requirements for 175 their transient numeric identifiers 177 o Protocol specifications that over-specify their transient numeric 178 identifiers 180 o Protocol implementations that simply fail to comply with the 181 specified requirements 183 A number of protocol specifications (too many of them) have simply 184 overlooked the security and privacy implications of transient numeric 185 identifiers. Examples of them are the specification of TCP ephemeral 186 ports in [RFC0793], the specification of TCP sequence numbers in 187 [RFC0793], or the specification of the DNS TxID in [RFC1035]. 189 On the other hand, there are a number of protocol specifications that 190 over-specify some of their associated transient numeric identifiers. 192 For example, [RFC4291] essentially overloads the semantics of IPv6 193 Interface Identifiers (IIDs) by embedding link-layer addresses in the 194 IPv6 IIDs, when the interoperability requirement of uniqueness could 195 be achieved in other ways that do not result in negative security and 196 privacy implications [RFC7721]. Similarly, [RFC2460] suggested the 197 use of a global counter for the generation of Fragment Identification 198 values, when the interoperability properties of uniqueness per {Src 199 IP, Dst IP} could be achieved with other algorithms that do not 200 result in negative security and privacy implications [RFC7739]. 202 Finally, there are protocol implementations that simply fail to 203 comply with existing protocol specifications. For example, some 204 popular operating systems (notably Microsoft Windows) still fail to 205 implement transport protocol ephemeral port randomization, as 206 recommended in [RFC6056]. 208 5. IPv4/IPv6 Identification 210 This section presents the timeline of the Identification field 211 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). 212 The reason for presenting both cases in the same section is to make 213 it evident that while the Identification value serves the same 214 purpose in both IPv4 and IPv6, the work and research done for the 215 IPv4 case did not affect IPv6 specifications or implementations. 217 The IPv4 Identification is specified in [RFC0791], which specifies 218 the interoperability requirements for the Identification field: the 219 sender must choose the Identification field to be unique for a given 220 source address, destination address, and protocol, for the time the 221 datagram (or any fragment of it) could be alive in the internet. It 222 suggests that a node may keep "a table of Identifiers, one entry for 223 each destination it has communicated with in the last maximum packet 224 lifetime for the internet", and suggests that "since the Identifier 225 field allows 65,536 different values, hosts may be able to simply use 226 unique identifiers independent of destination". The above has been 227 interpreted numerous times as a suggestion to employ per-destination 228 or global counters for the generation of Identification values. 229 While [RFC0791] does not suggest any flawed algorithm for the 230 generation of Identification values, the specification omits a 231 discussion of the security and privacy implications of predictable 232 Identification values. This has resulted in many IPv4 233 implementations generating predictable fragment Identification values 234 by means of a global counter, at least at some point in time. 236 The IPv6 Identification was originally specified in [RFC1883]. It 237 serves the same purpose as its IPv4 counterpart, with the only 238 difference residing in the length of the corresponding field, and 239 that while the IPv4 Identification field is part of the base IPv4 240 header, in the IPv6 case it is part of the Fragment header (which may 241 or may not be present in an IPv6 packet). [RFC1883] states, in 242 Section 4.5, that the Identification must be different than that of 243 any other fragmented packet sent recently (within the maximum likely 244 lifetime of a packet) with the same Source Address and Destination 245 Address. Subsequently, it notes that this requirement can be met by 246 means of a wrap-around 32-bit counter that is incremented each time a 247 packet must be fragmented, and that it is an implementation choice 248 whether to use a global or a per-destination counter. Thus, the 249 implementation of the IPv6 Identification is similar to that of the 250 IPv4 case, with the only difference that in the IPv6 case the 251 suggestions to use simple counters is more explicit. [RFC2460] was 252 the first revision of the core IPv6 specification, and maintained the 253 same text for the specification of the IPv6 Identification field. 254 [RFC8200], the second revision of the core IPv6 specification, 255 removes the suggestion from [RFC2460] to use a counter for the 256 generation of IPv6 Identification values, and points to [RFC7739] for 257 sample algorithms for their generation. 259 September 1981: 260 [RFC0791] specifies the interoperability requirements for IPv4 261 Identification value, but does not perform a vulnerability 262 assessment of this transient numeric identifier. 264 December 1995: 265 [RFC1883], the first specification of the IPv6 protocol, is 266 published. It suggests that a counter be used to generate the 267 IPv6 Identification value, and notes that it is an implementation 268 choice whether to maintain a single counter for the node or 269 multiple counters, e.g., one for each of the node's possible 270 source addresses, or one for each active (source address, 271 destination address) combination. 273 December 1998: 274 [Sanfilippo1998a] finds that predictable IPv4 Identification 275 values (generated by most popular implementations) can be 276 leveraged to count the number of packets sent by a target node. 277 [Sanfilippo1998b] explains how to leverage the same vulnerability 278 to implement a port-scanning technique known as dumb/idle scan. A 279 tool that implements this attack is publicly released. 281 December 1998: 282 [RFC2460], a revision of the IPv6 specification, is published, 283 obsoleting [RFC1883]. It maintains the same specification of the 284 IPv6 Identification field as its predecessor ([RFC1883]). 286 November 1999: 288 [Sanfilippo1999] discusses how to leverage predictable IPv4 289 Identification to uncover the rules of a number of firewalls. 291 December 1998: 292 OpenBSD implements randomization of the IPv4 Identification field 293 [OpenBSD-IPv4-ID]. This feature eventually shipped with OpenBSD 294 2.5. 296 November 1999: 297 [Bellovin2002] explains how the IPv4 Identification field can be 298 exploited to count the number of systems behind a NAT. 300 September 2002: 301 [Fyodor2002] explains how to implement a stealth port-scanning 302 technique by leveraging nodes that employ predictable IPv4 303 Identification values. 305 October 2003: 306 OpenBSD implements randomization of the IPv6 Identification field 307 [OpenBSD-IPv6-ID]. This feature eventually shipped with OpenBSD 308 3.4. 310 December 2003: 311 [Zalewski2003] explains a technique to perform TCP data injection 312 attack based on predictable IPv4 identification values which 313 requires less effort than TCP injection attacks performed with 314 bare TCP packets. 316 November 2005: 317 [Silbersack2005] discusses shortcoming in a number of techniques 318 to mitigate predictable IPv4 Identification values. 320 October 2007: 321 [Klein2007] describes a weakness in the pseudo random number 322 generator (PRNG) in use for the generation of the IP 323 Identification by a number of operating systems. 325 June 2011: 326 [Gont2011] describes how to perform idle scan attacks in IPv6. 328 November 2011: 329 Linux mitigates predictable IPv6 Identification values 330 [RedHat2011] [SUSE2011] [Ubuntu2011]. 332 December 2011: 333 [draft-gont-6man-predictable-fragment-id-00] describes the 334 security implications of predictable IPv6 Identification values, 335 and possible mitigations. This document is published on the 336 Standards Track, meaning to formally update [RFC2460], to 337 introduce security and privacy requirements on IPv6 Identification 338 values. 340 May 2012: 341 [Gont2012] notes that some major IPv6 implementations still employ 342 predictable IPv6 Identification values. 344 March 2013: 345 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but 346 changes the track to "BCP" (while still formally updating 347 [RFC2460]), publishing the resulting document as 348 [draft-ietf-6man-predictable-fragment-id-00]. 350 June 2013: 351 A patch that implements IPv6-based idle-scan in nmap is submitted 352 [Morbitzer2013]. 354 December 2014: 355 The 6man WG changes the status of 356 [draft-ietf-6man-predictable-fragment-id-01] to "Informational" 357 and publishes it as [draft-ietf-6man-predictable-fragment-id-02]. 358 As a result, it no longer formally updates [RFC2460]. 360 June 2015: 361 [draft-ietf-6man-predictable-fragment-id-08] notes that some 362 popular host and router implementations still employ predictable 363 IPv6 Identification values. 365 February 2016: 366 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) 367 analyzes the security and privacy implications of predictable IPv6 368 Identification values, and provides guidance for selecting an 369 algorithm to generate such values. However, being published on 370 the Informational track, it does not formally update [RFC2460]. 372 June 2016: 373 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the 374 suggestion from RFC2460 to use a counter for the generation of 375 IPv6 Identification values, but does not perform a vulnerability 376 analisys of the generation of IPv6 Identification values. 378 July 2017: 379 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], 380 obsoleting [RFC2460], and pointing to [RFC7739] for sample 381 algorithms for the generation of IPv6 Fragment Identification 382 values. 384 June 2019: 385 [IPID-DEV] notes that the IPv6 ID generators of two popular 386 operating systems are flawed. 388 6. TCP Initial Sequence Numbers (ISNs) 390 [RFC0793] suggests that the choice of the ISN of a connection is not 391 arbitrary, but aims to reduce the chances of a stale segment from 392 being accepted by a new incarnation of a previous connection. 393 [RFC0793] suggests the use of a global 32-bit ISN generator that is 394 incremented by 1 roughly every 4 microseconds. However, as a matter 395 of fact, protection against stale segments from a previous 396 incarnation of the connection is enforced by preventing the creation 397 of a new incarnation of a previous connection before 2*MSL have 398 passed since a segment corresponding to the old incarnation was last 399 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This 400 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept 401 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are 402 monotonically increasing across connections, many stacks (e.g., 403 4.2BSD-derived) use the ISN of an incoming SYN segment to perform 404 "heuristics" that enable the creation of a new incarnation of a 405 connection while the previous incarnation is still in the TIME-WAIT 406 state (see p. 945 of [Wright1994]). This avoids an interoperability 407 problem that may arise when a node establishes connections to a 408 specific TCP end-point at a high rate [Silbersack2005]. 410 The interoperability requirements for TCP ISNs are probably not 411 clearly spelled out as one would expect. Furthermore, the suggestion 412 of employing a global counter in [RFC0793] negatively affects the 413 security and privacy properties of the protocol. 415 September 1981: 416 [RFC0793], suggests the use of a global 32-bit ISN generator, 417 whose lower bit is incremented roughly every 4 microseconds. 418 However, such an ISN generator makes it trivial to predict the ISN 419 that a TCP will use for new connections, thus allowing a variety 420 of attacks against TCP. 422 February 1985: 423 [Morris1985] was the first to describe how to exploit predictable 424 TCP ISNs for forging TCP connections that could then be leveraged 425 for trust relationship exploitation. 427 April 1989: 428 [Bellovin1989] discussed the security considerations for 429 predictable ISNs (along with a range of other protocol-based 430 vulnerabilities). 432 February 1995: 433 [Shimomura1995] reported a real-world exploitation of the attack 434 described in 1985 (ten years before) in [Morris1985]. 436 May 1996: 437 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 438 to address predictable TCP ISNs. The same concept specified in 439 this document for TCP ISNs was later proposed for TCP ephemeral 440 ports [RFC6056], TCP Timestamps, and eventually even IPv6 441 Interface Identifiers [RFC7217]. 443 July 1996: 444 OpenBSD implements TCP ISN randomization based on random 445 increments (please see Appendix A.2 of 446 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I]. The 447 feature eventually shipped with OpenBSD 2.0. 449 December 2000: 450 OpenBSD implements TCP ISN randomization using simple 451 randomization (please see Section 7.1 of 452 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R]. The 453 feature eventually shipped with OpenBSD 2.9. 455 March 2001: 456 [Zalewski2001] provides a detailed analysis of statistical 457 weaknesses in some ISN generators, and includes a survey of the 458 algorithms in use by popular TCP implementations. 460 May 2001: 461 Vulnerability advisories [CERT2001] [USCERT2001] are released 462 regarding statistical weaknesses in some ISN generators, affecting 463 popular TCP/IP implementations. 465 March 2002: 466 [Zalewski2002] updates and complements [Zalewski2001]. It 467 concludes that "while some vendors [...] reacted promptly and 468 tested their solutions properly, many still either ignored the 469 issue and never evaluated their implementations, or implemented a 470 flawed solution that apparently was not tested using a known 471 approach" [Zalewski2002]. 473 June 2007: 474 OpenBSD implements TCP ISN randomization based on the algorithm 475 specified in [RFC1948] (currently obsoleted by [RFC6528]) for the 476 TCP endpoint that performs the active open, while keeping the 477 simple randomization scheme for the endpoint performing the 478 passive open [OpenBSD-TCP-ISN-H]. This provides monotonically- 479 increasing ISNs for the client side (allowing the BSD heuristics 480 to work as expexted), while avoiding any patterns in the ISN 481 generation for the server side. This feature eventually shipped 482 with OpenBSD 4.2. 484 February 2012: 485 [RFC6528], after 27 years of Morris' original work [Morris1985], 486 formally updates [RFC0793] to mitigate predictable TCP ISNs. 488 August 2014: 489 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 490 protocol specification, incorporates the algorithm specified in 491 [RFC6528] as the recommended algorithm for TCP ISN generation. 493 7. IPv6 Interface Identifiers (IIDs) 495 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC 496 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section 497 focuses on Interface Identifiers resulting from SLAAC. 499 The Interface Identifier of stable (traditional) IPv6 addresses 500 resulting from SLAAC have traditionally resulted in the underlying 501 link-layer address being embedded in the IID.At the time, employing 502 the underlying link-layer address for the IID was seen as a 503 convenient way to obtain a unique address. However, recent awareness 504 about the security and privacy properties of this approach [RFC7707] 505 [RFC7721] has led to the replacement of this flawed scheme with an 506 alternative one [RFC7217] [RFC8064] that does not negatively affect 507 the security and privacy properties of the protocol. 509 January 1997: 510 [RFC2073] specifies the syntax of IPv6 global addresses (referred 511 to as "An IPv6 Provider-Based Unicast Address Format" at the 512 time), consistent with the IPv6 addressing architecture specified 513 in [RFC1884]. Hosts are recommended to "generate addresses using 514 link-specific addresses as Interface ID such as 48 bit IEEE-802 515 MAC addresses". 517 July 1998: 518 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address 519 Format" (obsoleting [RFC2373]) changing the size of the Interface 520 ID to 64 bits, and specifies that that IIDs must be constructed in 521 IEEE EUI-64 format. How such identifiers are constructed becomes 522 specified in the appropriate "IPv6 over " specification such 523 as "IPv6 over Ethernet". 525 January 2001: 527 [RFC3041] recognizes the problem of network activity correlation, 528 and specifies temporary addresses. Temporary addresses are to be 529 used along with stable addresses. 531 August 2003: 532 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure 533 historic. The syntax and recommendations for the traditional 534 stable IIDs remain unchanged, though. 536 February 2006: 537 [RFC4291] is published as the latest "IP Version 6 Addressing 538 Architecture", requiring the IIDs of the traditional (stable) 539 autoconfigured addresses to employ the Modified EUI-64 format. 540 The details of constructing such interface identifiers are defined 541 in the appropriate "IPv6 over " specifications. 543 March 2008: 544 [RFC5157] provides hints regarding how patterns in IPv6 addresses 545 could be leveraged for the purpose of address scanning. 547 December 2011: 548 [draft-gont-6man-stable-privacy-addresses-00] notes that the 549 traditional scheme for generating stable addresses allows for 550 address scanning, and also does not prevent active node tracking. 551 It also specifies an alternative algorithm meant to replace IIDs 552 based on Modified EUI-64 format identifiers. 554 November 2012: 555 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a 556 working group item (as 557 [draft-ietf-6man-stable-privacy-addresses-00]). However, the 558 specified algorithm no longer formally replaces the Modified 559 EUI-64 format identifiers. 561 February 2013: 562 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages 563 IPv6 address patterns is released [Gont2013]. 565 July 2013: 566 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on 567 the security and privacy properties of all known algorithms for 568 generating IPv6 IIDs. 570 January 2014: 571 The 6man WG publishes [draft-ietf-6man-default-iids-00] 572 ("Recommendation on Stable IPv6 Interface Identifiers"), 573 recommending [I-D.ietf-6man-stable-privacy-addresses] for the 574 generation of stable addresses. 576 April 2014: 577 [RFC7217] is published, specifying "A Method for Generating 578 Semantically Opaque Interface Identifiers with IPv6 Stateless 579 Address Autoconfiguration (SLAAC)" as an alternative to (but *not* 580 replacement of) Modified EUI-64 format IIDs. 582 March 2016: 583 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning] and later 584 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network 585 Reconnaissance in IPv6 Networks", is published. 587 March 2016: 588 [RFC7721] (formerly 589 [I-D.cooper-6man-ipv6-address-generation-privacy] and later 590 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security 591 and Privacy Considerations for IPv6 Address Generation 592 Mechanisms", is published. 594 May 2016: 595 [draft-gont-6man-non-stable-iids-00] is published, with the goal 596 of specifying requirements for non-stable addresses, and updating 597 [RFC4941] such that use of only temporary addresses is allowed. 599 May 2016: 600 [draft-gont-6man-address-usage-recommendations-00] is published, 601 providing an analysis of how different aspects on an address (from 602 stability to usage mode) affect their corresponding security and 603 privacy properties, and meaning to eventually provide advice in 604 this area. 606 February 2017: 607 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6 608 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), 609 with requirements for stable addresses and a recommendation to 610 employ [RFC7217] for the generation of stable addresses. It 611 formally updated a large number of RFCs. 613 March 2018: 614 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the 615 6man WG), to address flaws in [RFC4941] by revising it (as an 616 alternative to the [draft-gont-6man-non-stable-iids-00] effort, 617 published in March 2016). 619 July 2018: 620 [draft-ietf-6man-rfc4941bis-00] is adopted (as 621 [draft-fgont-6man-rfc4941bis-00]) as a WG item of the 6man WG. 623 March 2020: 625 [I-D.ietf-6man-rfc4941bis] passes WGLC. 627 December 2020: 628 [I-D.ietf-6man-rfc4941bis] is finally approved by the IESG for 629 publication as an RFC. 631 8. NTP Reference IDs (REFIDs) 633 NTP [RFC5905] Reference IDs are employed to avoid degree-one timing 634 loops in scenarios where two NTP peers are (mutually) the time source 635 of each other. 637 June 2010: 638 [RFC5905], "Network Time Protocol Version 4: Protocol and 639 Algorithms Specification" is published. It specifies that for NTP 640 peers with stratum higher than 1 the REFID embeds the IPv4 Address 641 of the time source or an MD5 hash of the IPv6 address of the time 642 source. 644 July 2016: 645 [draft-stenn-ntp-not-you-refid-00] is published, describing the 646 information leakage produced via de NTP REFID. It proposes that 647 NTP returns a special REFID when a packet employs an IP Source 648 Address that is not believed to be a current NTP peer, but 649 otherwise generates and returns the traditional REFID. It is 650 subsequently adopted by the NTP WG as 651 [I-D.ietf-ntp-refid-updates]. 653 April 2019: 654 [Gont-NTP] notes that the proposed fix specified in 655 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub- 656 optimal. 658 9. Transport Protocol Ephemeral Port Numbers 660 Most (if not all) transport protocols employ "port numbers" to 661 demultiplex packets to the corresponding transport protocol 662 instances. 664 August 1980: 665 [RFC0768] notes that the UDP source port is optional and 666 identifies the port of the sending process. It does not specify 667 interoperability requirements for source port selection, nor does 668 it suggest possible ways to select port numbers. Most popular 669 implementations end up selecting source ports from a system-wide 670 global counter. 672 September 1981: 674 [RFC0793] (the TCP specification) essentially describes the use of 675 port numbers, and specifies that port numbers should result in a 676 unique socket pair (local address, local port, remote address, 677 remote port). How ephemeral ports (i.e. port numbers for "active 678 opens") are selected, and the port range from which they are 679 selected, are left unspecified. 681 July 1996: 682 OpenBSD implements ephemeral port randomization [OpenBSD-PR]. The 683 feature eventually shipped with OpenBSD 2.0. 685 January 2009: 686 [RFC5452] mandates the use of port randomization for DNS 687 resolvers, and mandates that implementations must randomize ports 688 from the range (53 or 1024, and above) or the largest possible 689 port range. It does not recommend possible algorithms for port 690 randomization, although the document specifically targets DNS 691 resolvers, for which a simple port randomization suffices (e.g. 692 Algorithm 1 of [RFC6056]). This document led to the 693 implementation of port randomization in the DNS resolver 694 themselves, rather than in the underlying transport-protocols. 696 January 2011: 697 [RFC6056] notes that many TCP and UDP implementations result in 698 predictable port numbers, and also notes that many implementations 699 select port numbers from a small portion of the whole port number 700 space. It recommends the implementation and use of ephemeral port 701 randomization, proposes a number of possible algorithms for port 702 randomization, and also recommends to randomize port numbers over 703 the range 1024-65535. 705 March 2016: 706 [NIST-NTP] reports a non-normal distribution of the ephemeral port 707 numbers employed by the NTP clients of an Internet Time Service. 709 April 2019: 710 [I-D.gont-ntp-port-randomization] notes that some NTP 711 implementations employ the NTP service port (123) as the local 712 port for non-symmetric modes, and aims to update the NTP 713 specification to recommend port randomization in such cases, in 714 line with [RFC6056]. The proposal experiences some push-back in 715 the relevant working group (NTP WG) [NTP-PORTR], but is finally 716 adopted as a working group item as 717 [I-D.ietf-ntp-port-randomization]. 719 September 2019: 720 [I-D.ietf-ntp-port-randomization] passes its WGLC. 722 10. IANA Considerations 724 There are no IANA registries within this document. The RFC-Editor 725 can remove this section before publication of this document as an 726 RFC. 728 11. Security Considerations 730 This document analyzes the timeline of the specification and 731 implementation of the transient numeric identifiers of some sample 732 IETF protocols, and how the security and privacy properties of such 733 protocols have been affected as a result of it. It provides concrete 734 evidence that advice in this area is warranted. 736 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol 737 specifications to specify the interoperability requirements for their 738 transient numeric identifiers, to do a warranted vulnerability 739 assessment of such transient numeric identifiers, and to recommend 740 possible algorithms for their generation, such that the 741 interoperability requirements are complied with, while any negative 742 security and privacy properties of these transient numeric 743 identifiers are mitigated. 745 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes 746 transient numeric identifiers based on their interoperability 747 requirements and their associated failure modes, and recommends 748 possible algorithms that can comply with those requirements without 749 negatively affecting the security and privacy properties of the 750 corresponding protocols. 752 12. Acknowledgements 754 The authors would like to thank (in alphabetical order) Bernard 755 Aboba, Dave Crocker, Theo de Raadt, Guillermo Gont, Christian 756 Huitema, Kris Shrishak, Joe Touch, and Christopher Wood, for 757 providing valuable comments on earlier versions of this document. 759 The authors would like to thank (in alphabetical order) Steven 760 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 761 providing valuable comments on [I-D.gont-predictable-numeric-ids], on 762 which this document is based. 764 Section 6 of this document borrows text from [RFC6528], authored by 765 Fernando Gont and Steven Bellovin. 767 The authors would like to thank Christopher Wood for his guidance 768 during the publication process of this document. 770 The authors would like to thank Diego Armando Maradona for his magic 771 and inspiration. 773 13. References 775 13.1. Normative References 777 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 778 DOI 10.17487/RFC0768, August 1980, 779 . 781 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 782 DOI 10.17487/RFC0791, September 1981, 783 . 785 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 786 RFC 793, DOI 10.17487/RFC0793, September 1981, 787 . 789 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 790 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 791 1992, . 793 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 794 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, 795 December 1995, . 797 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 798 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 799 December 1995, . 801 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. 802 Postel, "An IPv6 Provider-Based Unicast Address Format", 803 RFC 2073, DOI 10.17487/RFC2073, January 1997, 804 . 806 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 807 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 808 . 810 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 811 Aggregatable Global Unicast Address Format", RFC 2374, 812 DOI 10.17487/RFC2374, July 1998, 813 . 815 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 816 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 817 December 1998, . 819 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 820 Stateless Address Autoconfiguration in IPv6", RFC 3041, 821 DOI 10.17487/RFC3041, January 2001, 822 . 824 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 825 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 826 August 2003, . 828 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 829 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 830 2006, . 832 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 833 Address Autoconfiguration", RFC 4862, 834 DOI 10.17487/RFC4862, September 2007, 835 . 837 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 838 Extensions for Stateless Address Autoconfiguration in 839 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 840 . 842 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 843 Resilient against Forged Answers", RFC 5452, 844 DOI 10.17487/RFC5452, January 2009, 845 . 847 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 848 Protocol Port Randomization", BCP 156, RFC 6056, 849 DOI 10.17487/RFC6056, January 2011, 850 . 852 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 853 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 854 2012, . 856 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 857 Interface Identifiers with IPv6 Stateless Address 858 Autoconfiguration (SLAAC)", RFC 7217, 859 DOI 10.17487/RFC7217, April 2014, 860 . 862 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 863 (IPv6) Specification", STD 86, RFC 8200, 864 DOI 10.17487/RFC8200, July 2017, 865 . 867 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 868 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 869 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 870 RFC 8415, DOI 10.17487/RFC8415, November 2018, 871 . 873 13.2. Informative References 875 [Bellovin1989] 876 Bellovin, S., "Security Problems in the TCP/IP Protocol 877 Suite", Computer Communications Review, vol. 19, no. 2, 878 pp. 32-48, 1989, 879 . 881 [Bellovin2002] 882 Bellovin, S., "A Technique for Counting NATted Hosts", 883 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 885 [CERT2001] 886 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 887 TCP/IP Initial Sequence Numbers", 2001, 888 . 890 [draft-fgont-6man-rfc4941bis-00] 891 Gont, F., Krishnan, S., Narten, T., and R. Draves, 892 "Privacy Extensions for Stateless Address 893 Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00 894 (work in progress), March 2018. 896 [draft-gont-6man-address-usage-recommendations-00] 897 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", 898 draft-gont-6man-address-usage-recommendations-00 (work in 899 progress), May 2016. 901 [draft-gont-6man-non-stable-iids-00] 902 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 903 Interface Identifiers", draft-gont-6man-non-stable-iids-00 904 (work in progress), May 2016. 906 [draft-gont-6man-predictable-fragment-id-00] 907 Gont, F., "Security Implications of Predictable Fragment 908 Identification Values", draft-gont-6man-predictable- 909 fragment-id-00 (work in progress), December 2011. 911 [draft-gont-6man-stable-privacy-addresses-00] 912 Gont, F., "A method for Generating Stable Privacy-Enhanced 913 Addresses with IPv6 Stateless Address Autoconfiguration 914 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00 915 (work in progress), December 2011. 917 [draft-ietf-6man-default-iids-00] 918 Gont, F., Cooper, A., Thaler, D., and W. Liu, 919 "Recommendation on Stable IPv6 Interface Identifiers", 920 draft-ietf-6man-default-iids-00 (work in progress), July 921 2014. 923 [draft-ietf-6man-predictable-fragment-id-00] 924 Gont, F., "Security Implications of Predictable Fragment 925 Identification Values", draft-ietf-6man-predictable- 926 fragment-id-00 (work in progress), March 2013. 928 [draft-ietf-6man-predictable-fragment-id-01] 929 Gont, F., "Security Implications of Predictable Fragment 930 Identification Values", draft-ietf-6man-predictable- 931 fragment-id-01 (work in progress), April 2014. 933 [draft-ietf-6man-predictable-fragment-id-02] 934 Gont, F., "Security Implications of Predictable Fragment 935 Identification Values", draft-ietf-6man-predictable- 936 fragment-id-02 (work in progress), December 2014. 938 [draft-ietf-6man-predictable-fragment-id-08] 939 Gont, F., "Security Implications of Predictable Fragment 940 Identification Values", draft-ietf-6man-predictable- 941 fragment-id-08 (work in progress), June 2015. 943 [draft-ietf-6man-rfc4941bis-00] 944 Gont, F., Krishnan, S., Narten, T., and R. Draves, 945 "Privacy Extensions for Stateless Address 946 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00 947 (work in progress), July 2018. 949 [draft-ietf-6man-stable-privacy-addresses-00] 950 Gont, F., "A method for Generating Stable Privacy-Enhanced 951 Addresses with IPv6 Stateless Address Autoconfiguration 952 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 953 (work in progress), May 2012. 955 [draft-ietf-ntp-refid-updates-00] 956 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 957 REFID", draft-ietf-ntp-refid-updates-00 (work in 958 progress), November 2016. 960 [draft-stenn-ntp-not-you-refid-00] 961 Goldberg, S. and S. KrishnansTENN, "Network Time Protocol 962 Not You REFID", draft-stenn-ntp-not-you-refid-00 (work in 963 progress), July 2016. 965 [Fyodor2002] 966 Fyodor, "Idle scanning and related IP ID games", 2002, 967 . 969 [Gont-NTP] 970 Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- 971 05", Post to the NTP WG mailing list Message-ID: 972 , 973 April 2019, . 976 [Gont2011] 977 Gont, F., "Hacking IPv6 Networks (training course)", Hack 978 In Paris 2011 Conference Paris, France, June 2011. 980 [Gont2012] 981 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 982 Conference Ottawa, Canada. May 11-12, 2012, May 2012. 984 [Gont2013] 985 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit 986 (help wanted!)", Message posted to the IPv6 Hackers 987 mailing-list Message-ID: 988 <51184548.3030105@si6networks.com>, 1995, 989 . 992 [I-D.cooper-6man-ipv6-address-generation-privacy] 993 Cooper, A., Gont, F., and D. Thaler, "Privacy 994 Considerations for IPv6 Address Generation Mechanisms", 995 draft-cooper-6man-ipv6-address-generation-privacy-00 (work 996 in progress), July 2013. 998 [I-D.eddy-rfc793bis-04] 999 Eddy, W., "Transmission Control Protocol Specification", 1000 draft-eddy-rfc793bis-04 (work in progress), August 2014. 1002 [I-D.gont-6man-predictable-fragment-id] 1003 Gont, F., "Security Implications of Predictable Fragment 1004 Identification Values", draft-gont-6man-predictable- 1005 fragment-id-03 (work in progress), January 2013. 1007 [I-D.gont-6man-stable-privacy-addresses] 1008 Gont, F., "A method for Generating Stable Privacy-Enhanced 1009 Addresses with IPv6 Stateless Address Autoconfiguration 1010 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01 1011 (work in progress), March 2012. 1013 [I-D.gont-ntp-port-randomization] 1014 Gont, F. and G. Gont, "Port Randomization in the Network 1015 Time Protocol Version 4", draft-gont-ntp-port- 1016 randomization-04 (work in progress), August 2019. 1018 [I-D.gont-numeric-ids-sec-considerations] 1019 Gont, F. and I. Arce, "Security Considerations for 1020 Transient Numeric Identifiers Employed in Network 1021 Protocols", draft-gont-numeric-ids-sec-considerations-06 1022 (work in progress), December 2020. 1024 [I-D.gont-opsec-ipv6-host-scanning] 1025 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1026 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in 1027 progress), October 2012. 1029 [I-D.gont-predictable-numeric-ids] 1030 Gont, F. and I. Arce, "Security and Privacy Implications 1031 of Numeric Identifiers Employed in Network Protocols", 1032 draft-gont-predictable-numeric-ids-03 (work in progress), 1033 March 2019. 1035 [I-D.ietf-6man-default-iids] 1036 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1037 "Recommendation on Stable IPv6 Interface Identifiers", 1038 draft-ietf-6man-default-iids-16 (work in progress), 1039 September 2016. 1041 [I-D.ietf-6man-ipv6-address-generation-privacy] 1042 Cooper, A., Gont, F., and D. Thaler, "Privacy 1043 Considerations for IPv6 Address Generation Mechanisms", 1044 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 1045 in progress), September 2015. 1047 [I-D.ietf-6man-predictable-fragment-id] 1048 Gont, F., "Security Implications of Predictable Fragment 1049 Identification Values", draft-ietf-6man-predictable- 1050 fragment-id-10 (work in progress), October 2015. 1052 [I-D.ietf-6man-rfc2460bis] 1053 Deering, S. and R. Hinden, "Internet Protocol, Version 6 1054 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 1055 in progress), May 2017. 1057 [I-D.ietf-6man-rfc4941bis] 1058 Gont, F., Krishnan, S., Narten, T., and R. Draves, 1059 "Temporary Address Extensions for Stateless Address 1060 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12 1061 (work in progress), November 2020. 1063 [I-D.ietf-6man-stable-privacy-addresses] 1064 Gont, F., "A Method for Generating Semantically Opaque 1065 Interface Identifiers with IPv6 Stateless Address 1066 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 1067 privacy-addresses-17 (work in progress), January 2014. 1069 [I-D.ietf-ntp-port-randomization] 1070 Gont, F., Gont, G., and M. Lichvar, "Port Randomization in 1071 the Network Time Protocol Version 4", draft-ietf-ntp-port- 1072 randomization-06 (work in progress), September 2020. 1074 [I-D.ietf-ntp-refid-updates] 1075 Stenn, H. and S. Goldberg, "Network Time Protocol REFID 1076 Updates", draft-ietf-ntp-refid-updates-05 (work in 1077 progress), March 2019. 1079 [I-D.ietf-opsec-ipv6-host-scanning] 1080 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1081 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 1082 progress), August 2015. 1084 [I-D.irtf-pearg-numeric-ids-generation] 1085 Gont, F. and I. Arce, "On the Generation of Transient 1086 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 1087 generation-04 (work in progress), December 2020. 1089 [IANA-PROT] 1090 IANA, "Protocol Registries", 1091 . 1093 [IPID-DEV] 1094 Klein, A. and B. Pinkas, "From IP ID to Device ID and 1095 KASLR Bypass (Extended Version)", June 2019, 1096 . 1098 [IPv6-Toolkit] 1099 SI6 Networks, "SI6 Networks' IPv6 Toolkit", 1100 . 1102 [Klein2007] 1103 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 1104 Predictable IP ID Vulnerability", 2007, 1105 . 1108 [Morbitzer2013] 1109 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message 1110 posted to the nmap-dev mailing-list, 2013, 1111 . 1113 [Morris1985] 1114 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1115 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1116 NJ, 1985, 1117 . 1119 [NIST-NTP] 1120 Sherman, J. and J. Levine, "Usage Analysis of the NIST 1121 Internet Time Service", Journal of Research of the 1122 National Institute of Standards and Technology Volume 121, 1123 March 2016, . 1125 [NTP-PORTR] 1126 Gont, F., "[Ntp] New rev of the NTP port randomization I-D 1127 (Fwd: New Version Notification for draft-gont-ntp-port- 1128 randomization-01.txt)", 2019, 1129 . 1132 [OpenBSD-IPv4-ID] 1133 OpenBSD, "Randomization of the IPv4 Identification field", 1134 December 1998, 1135 . 1138 [OpenBSD-IPv6-ID] 1139 OpenBSD, "Randomization of the IPv6 Identification field", 1140 October 2003, 1141 . 1144 [OpenBSD-PR] 1145 OpenBSD, "Implementation of port randomization", July 1146 1996, . 1149 [OpenBSD-TCP-ISN-H] 1150 OpenBSD, "Implementation of RFC1948 for TCP ISN 1151 randomization", December 2000, 1152 . 1155 [OpenBSD-TCP-ISN-I] 1156 OpenBSD, "Implementation of TCP ISN randomization based on 1157 random increments", July 1996, 1158 . 1161 [OpenBSD-TCP-ISN-R] 1162 OpenBSD, "Implementation of TCP ISN randomization based on 1163 simple randomization", December 2000, 1164 . 1167 [RedHat2011] 1168 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 1169 Important: kernel security and bug fix update", 2011, 1170 . 1172 [RFC1035] Mockapetris, P., "Domain names - implementation and 1173 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1174 November 1987, . 1176 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1177 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1178 . 1180 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1181 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1182 . 1184 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1185 "Network Time Protocol Version 4: Protocol and Algorithms 1186 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1187 . 1189 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1190 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 1191 . 1193 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1194 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1195 2014, . 1197 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1198 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1199 . 1201 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1202 Considerations for IPv6 Address Generation Mechanisms", 1203 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1204 . 1206 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1207 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1208 February 2016, . 1210 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1211 "Recommendation on Stable IPv6 Interface Identifiers", 1212 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1213 . 1215 [Sanfilippo1998a] 1216 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1217 mailing-list, Mon Dec 14 1998, 1218 . 1220 [Sanfilippo1998b] 1221 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1222 1998, . 1224 [Sanfilippo1999] 1225 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1226 list, 1999, 1227 . 1229 [Schuba1993] 1230 Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME 1231 SYSTEM PROTOCOL", 1993, 1232 . 1235 [Shimomura1995] 1236 Shimomura, T., "Technical details of the attack described 1237 by Markoff in NYT", Message posted in USENET's 1238 comp.security.misc newsgroup Message-ID: 1239 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1240 . 1242 [Silbersack2005] 1243 Silbersack, M., "Improving TCP/IP security through 1244 randomization without sacrificing interoperability", 1245 EuroBSDCon 2005 Conference, 2005, 1246 . 1249 [SUSE2011] 1250 SUSE, "SUSE Security Announcement: Linux kernel security 1251 update (SUSE-SA:2011:046)", 2011, 1252 . 1255 [Ubuntu2011] 1256 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 1257 vulnerabilities", 2011, 1258 . 1260 [USCERT2001] 1261 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 1262 TCP/IP implementations may use statistically predictable 1263 initial sequence numbers", 2001, 1264 . 1266 [Wright1994] 1267 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1268 The Implementation", Addison-Wesley, 1994. 1270 [Zalewski2001] 1271 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1272 Number Analysis", 2001, 1273 . 1275 [Zalewski2002] 1276 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1277 Number Analysis - One Year Later", 2001, 1278 . 1280 [Zalewski2003] 1281 Zalewski, M., "A new TCP/IP blind data injection 1282 technique?", 2003, 1283 . 1285 Authors' Addresses 1286 Fernando Gont 1287 SI6 Networks 1288 Evaristo Carriego 2644 1289 Haedo, Provincia de Buenos Aires 1706 1290 Argentina 1292 Phone: +54 11 4650 8472 1293 Email: fgont@si6networks.com 1294 URI: https://www.si6networks.com 1296 Ivan Arce 1297 Quarkslab 1299 Email: iarce@quarkslab.com 1300 URI: https://www.quarkslab.com