idnits 2.17.00 (12 Aug 2021) /tmp/idnits24122/draft-irtf-pearg-numeric-ids-history-09.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 document date (27 January 2022) is 107 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2073 (Obsoleted by RFC 2374) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) == Outdated reference: draft-ietf-6man-rfc4941bis has been published as RFC 8981 == Outdated reference: draft-ietf-opsec-ipv6-host-scanning has been published as RFC 7707 == Outdated reference: draft-ietf-6man-stable-privacy-addresses has been published as RFC 7217 == Outdated reference: draft-ietf-6man-ipv6-address-generation-privacy has been published as RFC 7721 == Outdated reference: draft-ietf-6man-default-iids has been published as RFC 8064 == Outdated reference: A later version (-07) exists of draft-gont-numeric-ids-sec-considerations-06 == Outdated reference: A later version (-08) exists of draft-irtf-pearg-numeric-ids-generation-07 == Outdated reference: draft-ietf-6man-rfc2460bis has been published as RFC 8200 -- Duplicate reference: draft-ietf-ntp-refid-updates, mentioned in 'I-D.ietf-ntp-refid-updates', was also mentioned in 'Gont-NTP'. -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) == Outdated reference: A later version (-05) exists of draft-eddy-rfc793bis-04 -- Duplicate reference: RFC1948, mentioned in 'OpenBSD-TCP-ISN-H', was also mentioned in 'RFC1948'. -- Obsolete informational reference (is this intentional?): RFC 1948 (ref. 'OpenBSD-TCP-ISN-H') (Obsoleted by RFC 6528) == Outdated reference: draft-ietf-ntp-port-randomization has been published as RFC 9109 == Outdated reference: draft-ietf-6man-predictable-fragment-id has been published as RFC 7739 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 6 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 EdgeUno 4 Intended status: Informational I. Arce 5 Expires: 31 July 2022 Quarkslab 6 27 January 2022 8 Unfortunate History of Transient Numeric Identifiers 9 draft-irtf-pearg-numeric-ids-history-09 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. This 18 document is a product of the Privacy Enhancement and Assessment 19 Research Group (PEARG) in the IRTF. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 31 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Issues with the Specification of Transient Numeric 55 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 6 57 4.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 10 58 4.3. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . 12 59 4.4. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . 15 60 4.5. Transport Protocol Ephemeral Port Numbers . . . . . . . . 15 61 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 67 9.2. Informative References . . . . . . . . . . . . . . . . . 21 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 70 1. Introduction 72 Networking protocols employ a variety of transient numeric 73 identifiers for different protocol objects, such as IPv4 and IPv6 74 Fragment Identifiers [RFC0791] [RFC8200], IPv6 Interface Identifiers 75 (IIDs) [RFC4291], transport protocol ephemeral port numbers 76 [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], and DNS 77 Transaction IDs (TxIDs) [RFC1035]. These identifiers typically have 78 specific interoperability requirements (e.g. uniqueness during a 79 specified period of time), and associated failure severities when 80 such requirements are not met 81 [I-D.irtf-pearg-numeric-ids-generation]. 83 For more than 30 years, a large number of implementations of the TCP/ 84 IP protocol suite have been subject to a variety of attacks, with 85 effects ranging from Denial of Service (DoS) or data injection, to 86 information leakages that could be exploited for pervasive monitoring 87 [RFC7258]. The root cause of these issues has been, in many cases, 88 poor selection of transient numeric identifiers, usually as a result 89 of insufficient or misleading specifications. 91 For example, implementations have been subject to security or privacy 92 issues resulting from: 94 * Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 95 [Sanfilippo1998a], [RFC6274], and [RFC7739]) 97 * Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and 98 [RFC7217]) 100 * Predictable transport protocol ephemeral port numbers (see e.g. 101 [RFC6056] and [Silbersack2005]) 103 * Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. 104 [Morris1985], [Bellovin1989], and [RFC6528]) 106 * Predictable DNS TxIDs (see e.g. [Arce1997] and [Klein2007]) 108 These examples indicate that when new protocols are standardized or 109 implemented, the security and privacy properties of the associated 110 transient numeric identifiers tend to be overlooked, and 111 inappropriate algorithms to generate such identifiers (i.e. that 112 negatively affect the security or privacy properties of the protocol) 113 are either suggested in the specification or selected by 114 implementers. 116 This document contains a non-exhaustive timeline of the specification 117 and vulnerability disclosures related to some sample transient 118 numeric identifiers, including other work that has led to advances in 119 this area. This analysis indicates that: 121 * Vulnerabilities associated with the inappropriate generation of 122 transient numeric identifiers have affected protocol 123 implementations for an extremely long period of time. 125 * Such vulnerabilities, even when addressed for a given protocol 126 version, were later reintroduced in new versions or new 127 implementations of the same protocol. 129 * Standardization efforts that discuss and provide advice in this 130 area can have a positive effect on protocol specifications and 131 protocol implementations. 133 While it is generally possible to identify an algorithm that can 134 satisfy the interoperability requirements for a given transient 135 numeric identifier, this document provides empirical evidence that 136 doing so without negatively affecting the security or privacy 137 properties of the aforementioned protocols is non-trivial. Other 138 related documents ([I-D.irtf-pearg-numeric-ids-generation] and 139 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this 140 area, as motivated by the present document. 142 This document represents the consensus of the Privacy Enhancement and 143 Assessment Research Group (PEARG). 145 2. Terminology 147 Transient Numeric Identifier: 148 A data object in a protocol specification that can be used to 149 definitely distinguish a protocol object (a datagram, network 150 interface, transport protocol endpoint, session, etc) from all 151 other objects of the same type, in a given context. Transient 152 numeric identifiers are usually defined as a series of bits, and 153 represented using integer values. These identifiers are typically 154 dynamically selected, as opposed to statically-assigned numeric 155 identifiers (see e.g. [IANA-PROT]). We note that different 156 identifiers may have additional requirements or properties 157 depending on their specific use in a protocol. We use the term 158 "transient numeric identifier" (or simply "numeric identifier" or 159 "identifier" as short forms) as a generic term to refer to any 160 data object in a protocol specification that satisfies the 161 identification property stated above. 163 The terms "constant IID", "stable IID", and "temporary IID" are to be 164 interpreted as defined in [RFC7721]. 166 3. Threat Model 168 Throughout this document, we assume an attacker does not have 169 physical or logical access to the system(s) being attacked, and that 170 the attacker can only observe traffic explicitly directed to the 171 attacker. For example, an attacker cannot observe traffic 172 transferred between a sender and the receiver(s) of a target 173 protocol, but may be able to interact with any of these entities, 174 including by e.g. sending any traffic to them to sample transient 175 numeric identifiers employed by the target systems when communicating 176 with the attacker. 178 For example, when analyzing vulnerabilities associated with TCP 179 Initial Sequence Numbers (ISNs), we consider the attacker is unable 180 to capture network traffic corresponding to a TCP connection between 181 two other hosts. However, we consider the attacker is able to 182 communicate with any of these hosts (e.g., establish a TCP connection 183 with any of them), to e.g. sample the TCP ISNs employed by these 184 systems when communicating with the attacker. 186 Similarly, when considering host-tracking attacks based on IPv6 187 interface identifiers, we consider an attacker may learn the IPv6 188 address employed by a victim node if e.g. the address becomes exposed 189 as a result of the victim node communicating with an attacker- 190 operated server. Subsequently, an attacker may perform host-tracking 191 by probing a set of target addresses composed by a set of target 192 prefixes and the IPv6 interface identifier originally learned by the 193 attacker. Alternatively, an attacker may perform host tracking if 194 e.g. the victim node communicates with an attacker-operated server as 195 it moves from one location to another, those exposing its configured 196 addresses. We note that none of these scenarios requires the 197 attacker observe traffic not explicitly directed to the attacker. 199 4. Issues with the Specification of Transient Numeric Identifiers 201 While assessing protocol specifications regarding the use of 202 transient numeric identifiers, we have found that most of the issues 203 discussed in this document arise as a result of one of the following 204 conditions: 206 * Protocol specifications that under-specify the requirements for 207 their transient numeric identifiers 209 * Protocol specifications that over-specify their transient numeric 210 identifiers 212 * Protocol implementations that simply fail to comply with the 213 specified requirements 215 A number of protocol specifications have simply overlooked the 216 security and privacy implications of transient numeric identifiers. 217 Examples of them are the specification of TCP ephemeral ports in 218 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or 219 the specification of the DNS TxID in [RFC1035]. 221 On the other hand, there are a number of protocol specifications that 222 over-specify some of their associated transient numeric identifiers. 223 For example, [RFC4291] essentially overloads the semantics of IPv6 224 Interface Identifiers (IIDs) by embedding link-layer addresses in the 225 IPv6 IIDs, when the interoperability requirement of uniqueness could 226 be achieved in other ways that do not result in negative security and 227 privacy implications [RFC7721]. Similarly, [RFC2460] suggested the 228 use of a global counter for the generation of Fragment Identification 229 values, when the interoperability properties of uniqueness per {Src 230 IP, Dst IP} could be achieved with other algorithms that do not 231 result in negative security and privacy implications [RFC7739]. 233 Finally, there are protocol implementations that simply fail to 234 comply with existing protocol specifications. For example, some 235 popular operating systems (notably Microsoft Windows) still fail to 236 implement transport protocol ephemeral port randomization, as 237 recommended in [RFC6056]. 239 The following subsections document the timelines for a number of 240 sample transient numeric identifiers, that illustrate how the problem 241 discussed in this document has affected protocols from different 242 layers over time. These sample transient numeric identifiers have 243 different interoperability requirements and failure severities (see 244 Section 6 of [I-D.irtf-pearg-numeric-ids-generation]), and thus are 245 considered to be representative of the problem being analyzed in this 246 document. 248 4.1. IPv4/IPv6 Identification 250 This section presents the timeline of the Identification field 251 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). 252 The reason for presenting both cases in the same section is to make 253 it evident that while the Identification value serves the same 254 purpose in both IPv4 and IPv6, the work and research done for the 255 IPv4 case did not affect IPv6 specifications or implementations. 257 The IPv4 Identification is specified in [RFC0791], which specifies 258 the interoperability requirements for the Identification field: the 259 sender must choose the Identification field to be unique for a given 260 source address, destination address, and protocol, for the time the 261 datagram (or any fragment of it) could be alive in the internet. It 262 suggests that a node may keep "a table of Identifiers, one entry for 263 each destination it has communicated with in the last maximum packet 264 lifetime for the internet", and suggests that "since the Identifier 265 field allows 65,536 different values, hosts may be able to simply use 266 unique identifiers independent of destination". The above has been 267 interpreted numerous times as a suggestion to employ per-destination 268 or global counters for the generation of Identification values. 269 While [RFC0791] does not suggest any flawed algorithm for the 270 generation of Identification values, the specification omits a 271 discussion of the security and privacy implications of predictable 272 Identification values. This has resulted in many IPv4 273 implementations generating predictable fragment Identification values 274 by means of a global counter, at least at some point in time. 276 The IPv6 Identification was originally specified in [RFC1883]. It 277 serves the same purpose as its IPv4 counterpart, with the only 278 difference residing in the length of the corresponding field, and 279 that while the IPv4 Identification field is part of the base IPv4 280 header, in the IPv6 case it is part of the Fragment header (which may 281 or may not be present in an IPv6 packet). [RFC1883] states, in 282 Section 4.5, that the Identification must be different than that of 283 any other fragmented packet sent recently (within the maximum likely 284 lifetime of a packet) with the same Source Address and Destination 285 Address. Subsequently, it notes that this requirement can be met by 286 means of a wrap-around 32-bit counter that is incremented each time a 287 packet must be fragmented, and that it is an implementation choice 288 whether to use a global or a per-destination counter. Thus, the 289 implementation of the IPv6 Identification is similar to that of the 290 IPv4 case, with the only difference that in the IPv6 case the 291 suggestions to use simple counters is more explicit. [RFC2460] was 292 the first revision of the core IPv6 specification, and maintained the 293 same text for the specification of the IPv6 Identification field. 294 [RFC8200], the second revision of the core IPv6 specification, 295 removes the suggestion from [RFC2460] to use a counter for the 296 generation of IPv6 Identification values, and points to [RFC7739] for 297 sample algorithms for their generation. 299 September 1981: 300 [RFC0791] specifies the interoperability requirements for IPv4 301 Identification value, but does not perform a vulnerability 302 assessment of this transient numeric identifier. 304 December 1995: 305 [RFC1883], the first specification of the IPv6 protocol, is 306 published. It suggests that a counter be used to generate the 307 IPv6 Identification value, and notes that it is an implementation 308 choice whether to maintain a single counter for the node or 309 multiple counters, e.g., one for each of the node's possible 310 source addresses, or one for each active (source address, 311 destination address) combination. 313 December 1998: 314 [Sanfilippo1998a] finds that predictable IPv4 Identification 315 values (generated by most popular implementations) can be 316 leveraged to count the number of packets sent by a target node. 317 [Sanfilippo1998b] explains how to leverage the same vulnerability 318 to implement a port-scanning technique known as dumb/idle scan. A 319 tool that implements this attack is publicly released. 321 December 1998: 322 [RFC2460], a revision of the IPv6 specification, is published, 323 obsoleting [RFC1883]. It maintains the same specification of the 324 IPv6 Identification field as its predecessor ([RFC1883]). 326 December 1998: 327 OpenBSD implements randomization of the IPv4 Identification field 328 [OpenBSD-IPv4-ID]. 330 November 1999: 331 [Sanfilippo1999] discusses how to leverage predictable IPv4 332 Identification to uncover the rules of a number of firewalls. 334 November 1999: 335 [Bellovin2002] explains how the IPv4 Identification field can be 336 exploited to count the number of systems behind a NAT. 338 September 2002: 339 [Fyodor2002] explains how to implement a stealth port-scanning 340 technique by leveraging nodes that employ predictable IPv4 341 Identification values. 343 October 2003: 344 OpenBSD implements randomization of the IPv6 Identification field 345 [OpenBSD-IPv6-ID]. 347 December 2003: 348 [Zalewski2003] explains a technique to perform TCP data injection 349 attack based on predictable IPv4 identification values which 350 requires less effort than TCP injection attacks performed with 351 bare TCP packets. 353 November 2005: 354 [Silbersack2005] discusses shortcoming in a number of techniques 355 to mitigate predictable IPv4 Identification values. 357 October 2007: 358 [Klein2007] describes a weakness in the pseudo random number 359 generator (PRNG) in use for the generation of the IP 360 Identification by a number of operating systems. 362 June 2011: 363 [Gont2011] describes how to perform idle scan attacks in IPv6. 365 November 2011: 366 Linux mitigates predictable IPv6 Identification values 367 [RedHat2011] [SUSE2011] [Ubuntu2011]. 369 December 2011: 370 [draft-gont-6man-predictable-fragment-id-00] describes the 371 security implications of predictable IPv6 Identification values, 372 and possible mitigations. This document has the Intended Status 373 of "Standards Track", with the intention to formally update 374 [RFC2460], to introduce security and privacy requirements on IPv6 375 Identification values. 377 May 2012: 378 [Gont2012] notes that some major IPv6 implementations still employ 379 predictable IPv6 Identification values. 381 March 2013: 382 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but 383 changes the track to "BCP" (while still formally updating 384 [RFC2460]), publishing the resulting document as 385 [draft-ietf-6man-predictable-fragment-id-00]. 387 June 2013: 388 A patch that implements IPv6-based idle-scan in nmap is submitted 389 [Morbitzer2013]. 391 December 2014: 392 The 6man WG changes the Intended Status of 393 [draft-ietf-6man-predictable-fragment-id-01] to "Informational" 394 and publishes it as [draft-ietf-6man-predictable-fragment-id-02]. 395 As a result, it no longer formally updates [RFC2460]. 397 June 2015: 398 [draft-ietf-6man-predictable-fragment-id-08] notes that some 399 popular host and router implementations still employ predictable 400 IPv6 Identification values. 402 February 2016: 403 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) 404 analyzes the security and privacy implications of predictable IPv6 405 Identification values, and provides guidance for selecting an 406 algorithm to generate such values. However, being published with 407 the Intended Status of "Informational", it does not formally 408 update [RFC2460]. 410 June 2016: 411 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the 412 suggestion from RFC2460 to use a counter for the generation of 413 IPv6 Identification values, but does not perform a vulnerability 414 assessment of the generation of IPv6 Identification values. 416 July 2017: 417 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], 418 obsoleting [RFC2460], and pointing to [RFC7739] for sample 419 algorithms for the generation of IPv6 Fragment Identification 420 values. 422 June 2019: 423 [IPID-DEV] notes that the IPv6 ID generators of two popular 424 operating systems are flawed. 426 4.2. TCP Initial Sequence Numbers (ISNs) 428 [RFC0793] suggests that the choice of the ISN of a connection is not 429 arbitrary, but aims to reduce the chances of a stale segment from 430 being accepted by a new incarnation of a previous connection. 431 [RFC0793] suggests the use of a global 32-bit ISN generator that is 432 incremented by 1 roughly every 4 microseconds. However, as a matter 433 of fact, protection against stale segments from a previous 434 incarnation of the connection is enforced by preventing the creation 435 of a new incarnation of a previous connection before 2*MSL have 436 passed since a segment corresponding to the old incarnation was last 437 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This 438 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept 439 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are 440 monotonically increasing across connections, many stacks (e.g., 441 4.2BSD-derived) use the ISN of an incoming SYN segment to perform 442 "heuristics" that enable the creation of a new incarnation of a 443 connection while the previous incarnation is still in the TIME-WAIT 444 state (see p. 945 of [Wright1994]). This avoids an interoperability 445 problem that may arise when a node establishes connections to a 446 specific TCP end-point at a high rate [Silbersack2005]. 448 The interoperability requirements for TCP ISNs are probably not as 449 clearly spelled out as one would expect. Furthermore, the suggestion 450 of employing a global counter in [RFC0793] negatively affects the 451 security and privacy properties of the protocol. 453 September 1981: 454 [RFC0793], suggests the use of a global 32-bit ISN generator, 455 whose lower bit is incremented roughly every 4 microseconds. 456 However, such an ISN generator makes it trivial to predict the ISN 457 that a TCP instance will use for new connections, thus allowing a 458 variety of attacks against TCP. 460 February 1985: 461 [Morris1985] was the first to describe how to exploit predictable 462 TCP ISNs for forging TCP connections that could then be leveraged 463 for trust relationship exploitation. 465 April 1989: 466 [Bellovin1989] discussed the security considerations for 467 predictable ISNs (along with a range of other protocol-based 468 vulnerabilities). 470 February 1995: 471 [Shimomura1995] reported a real-world exploitation of the attack 472 described in 1985 (ten years before) in [Morris1985]. 474 May 1996: 475 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 476 to address predictable TCP ISNs. The same concept specified in 477 this document for TCP ISNs was later proposed for TCP ephemeral 478 ports [RFC6056], TCP Timestamps, and eventually even IPv6 479 Interface Identifiers [RFC7217]. 481 July 1996: 482 OpenBSD implements TCP ISN randomization based on random 483 increments (please see Appendix A.2 of 484 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I]. 486 December 2000: 487 OpenBSD implements TCP ISN randomization using simple 488 randomization (please see Section 7.1 of 489 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R]. 491 March 2001: 492 [Zalewski2001] provides a detailed analysis of statistical 493 weaknesses in some ISN generators, and includes a survey of the 494 algorithms in use by popular TCP implementations. 496 May 2001: 497 Vulnerability advisories [CERT2001] [USCERT2001] are released 498 regarding statistical weaknesses in some ISN generators, affecting 499 popular TCP/IP implementations. 501 March 2002: 502 [Zalewski2002] updates and complements [Zalewski2001]. It 503 concludes that "while some vendors [...] reacted promptly and 504 tested their solutions properly, many still either ignored the 505 issue and never evaluated their implementations, or implemented a 506 flawed solution that apparently was not tested using a known 507 approach" [Zalewski2002]. 509 June 2007: 510 OpenBSD implements TCP ISN randomization based on the algorithm 511 specified in [RFC1948] (currently obsoleted by [RFC6528]) for the 512 TCP endpoint that performs the active open, while keeping the 513 simple randomization scheme for the endpoint performing the 514 passive open [OpenBSD-TCP-ISN-H]. This provides monotonically- 515 increasing ISNs for the client side (allowing the BSD heuristics 516 to work as expected), while avoiding any patterns in the ISN 517 generation for the server side. 519 February 2012: 520 [RFC6528], published 27 years after Morris' original work 521 [Morris1985], formally updates [RFC0793] to mitigate predictable 522 TCP ISNs. 524 August 2014: 525 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 526 protocol specification, incorporates the algorithm specified in 527 [RFC6528] as the recommended algorithm for TCP ISN generation. 529 4.3. IPv6 Interface Identifiers (IIDs) 531 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC 532 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section 533 focuses on Interface Identifiers resulting from SLAAC. 535 The Interface Identifier of stable (traditional) IPv6 addresses 536 resulting from SLAAC have traditionally resulted in the underlying 537 link-layer address being embedded in the IID.At the time, employing 538 the underlying link-layer address for the IID was seen as a 539 convenient way to obtain a unique address. However, recent awareness 540 about the security and privacy properties of this approach [RFC7707] 541 [RFC7721] has led to the replacement of this flawed scheme with an 542 alternative one [RFC7217] [RFC8064] that does not negatively affect 543 the security and privacy properties of the protocol. 545 January 1997: 546 [RFC2073] specifies the syntax of IPv6 global addresses (referred 547 to as "An IPv6 Provider-Based Unicast Address Format" at the 548 time), consistent with the IPv6 addressing architecture specified 549 in [RFC1884]. Hosts are recommended to "generate addresses using 550 link-specific addresses as Interface ID such as 48 bit IEEE-802 551 MAC addresses". 553 July 1998: 554 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address 555 Format" (obsoleting [RFC2373]) changing the size of the Interface 556 ID to 64 bits, and specifies that that IIDs must be constructed in 557 IEEE EUI-64 format. How such identifiers are constructed becomes 558 specified in the appropriate "IPv6 over " specification such 559 as "IPv6 over Ethernet". 561 January 2001: 562 [RFC3041] recognizes the problem of network activity correlation, 563 and specifies temporary addresses. Temporary addresses are to be 564 used along with stable addresses. 566 August 2003: 567 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure 568 historic. The syntax and recommendations for the traditional 569 stable IIDs remain unchanged, though. 571 February 2006: 572 [RFC4291] is published as the latest "IP Version 6 Addressing 573 Architecture", requiring the IIDs of the traditional (stable) 574 autoconfigured addresses to employ the Modified EUI-64 format. 575 The details of constructing such interface identifiers are defined 576 in the appropriate "IPv6 over " specifications. 578 March 2008: 579 [RFC5157] provides hints regarding how patterns in IPv6 addresses 580 could be leveraged for the purpose of address scanning. 582 December 2011: 583 [draft-gont-6man-stable-privacy-addresses-00] notes that the 584 traditional scheme for generating stable addresses allows for 585 address scanning, and also does not prevent active node tracking. 586 It also specifies an alternative algorithm meant to replace IIDs 587 based on Modified EUI-64 format identifiers. 589 November 2012: 590 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a 591 working group item (as 592 [draft-ietf-6man-stable-privacy-addresses-00]). However, the 593 document no longer formally updates [RFC4291], and therefore the 594 specified algorithm no longer formally replaces the Modified 595 EUI-64 format identifiers. 597 February 2013: 598 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages 599 IPv6 address patterns is released [Gont2013]. 601 July 2013: 602 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on 603 the security and privacy properties of all known algorithms for 604 generating IPv6 IIDs. 606 January 2014: 607 The 6man WG publishes [draft-ietf-6man-default-iids-00] 608 ("Recommendation on Stable IPv6 Interface Identifiers"), 609 recommending [I-D.ietf-6man-stable-privacy-addresses] for the 610 generation of stable addresses. 612 April 2014: 613 [RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) is 614 published, specifying "A Method for Generating Semantically Opaque 615 Interface Identifiers with IPv6 Stateless Address 616 Autoconfiguration (SLAAC)" as an alternative to (but *not* 617 replacement of) Modified EUI-64 format IIDs. 619 March 2016: 620 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], and later 621 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network 622 Reconnaissance in IPv6 Networks", is published. 624 March 2016: 625 [RFC7721] (formerly 626 [I-D.cooper-6man-ipv6-address-generation-privacy] and later 627 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security 628 and Privacy Considerations for IPv6 Address Generation 629 Mechanisms", is published. 631 May 2016: 632 [draft-gont-6man-non-stable-iids-00] is published, with the goal 633 of specifying requirements for non-stable addresses, and updating 634 [RFC4941] such that use of only temporary addresses is allowed. 636 May 2016: 637 [draft-gont-6man-address-usage-recommendations-00] is published, 638 providing an analysis of how different aspects on an address (from 639 stability to usage mode) affect their corresponding security and 640 privacy properties, and meaning to eventually provide advice in 641 this area. 643 February 2017: 644 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6 645 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), 646 with requirements for stable addresses and a recommendation to 647 employ [RFC7217] for the generation of stable addresses. It 648 formally updates a large number of RFCs. 650 March 2018: 651 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the 652 6man WG), to address flaws in [RFC4941] by revising it (as an 653 alternative to the [draft-gont-6man-non-stable-iids-00] effort, 654 published in March 2016). 656 July 2018: 657 [draft-fgont-6man-rfc4941bis-00] is adopted (as 658 [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG. 660 December 2020: 661 [I-D.ietf-6man-rfc4941bis] is approved by the IESG for publication 662 as an RFC. 664 February 2021: 665 [I-D.ietf-6man-rfc4941bis] is finally published as [RFC8981]. 667 4.4. NTP Reference IDs (REFIDs) 669 The NTP [RFC5905] Reference ID is a 32-bit code identifying the 670 particular server or reference clock. Above stratum 1 (secondary 671 servers and clients), this value can be employed to avoid degree-one 672 timing loops; that is, scenarios where two NTP peers are (mutually) 673 the time source of each other. If using the IPv4 address family, the 674 identifier is the four-octet IPv4 address. If using the IPv6 address 675 family, it is the first four octets of the MD5 hash of the IPv6 676 address. 678 June 2010: 679 [RFC5905], "Network Time Protocol Version 4: Protocol and 680 Algorithms Specification" is published. It specifies that for NTP 681 peers with stratum higher than 1 the REFID embeds the IPv4 Address 682 of the time source or an MD5 hash of the IPv6 address of the time 683 source. 685 July 2016: 686 [draft-stenn-ntp-not-you-refid-00] is published, describing the 687 information leakage produced via the NTP REFID. It proposes that 688 NTP returns a special REFID when a packet employs an IP Source 689 Address that is not believed to be a current NTP peer, but 690 otherwise generates and returns the traditional REFID. It is 691 subsequently adopted by the NTP WG as 692 [I-D.ietf-ntp-refid-updates]. 694 April 2019: 695 [Gont-NTP] notes that the proposed fix specified in 696 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub- 697 optimal. 699 4.5. Transport Protocol Ephemeral Port Numbers 701 Most (if not all) transport protocols employ "port numbers" to 702 demultiplex packets to the corresponding transport protocol 703 instances. 705 August 1980: 706 [RFC0768] notes that the UDP source port is optional and 707 identifies the port of the sending process. It does not specify 708 interoperability requirements for source port selection, nor does 709 it suggest possible ways to select port numbers. Most popular 710 implementations end up selecting source ports from a system-wide 711 global counter. 713 September 1981: 714 [RFC0793] (the TCP specification) essentially describes the use of 715 port numbers, and specifies that port numbers should result in a 716 unique socket pair (local address, local port, remote address, 717 remote port). How ephemeral ports (i.e. port numbers for "active 718 opens") are selected, and the port range from which they are 719 selected, are left unspecified. 721 July 1996: 722 OpenBSD implements ephemeral port randomization [OpenBSD-PR]. 724 July 2008: 725 The CERT Coordination Centre published details of what became 726 known as the "Kaminsky Attack" [VU-800113] on the DNS. The attack 727 exploited the lack of source port randomization in many major DNS 728 implementations to perform cache poisoning in an effective and 729 practical manner. 731 January 2009: 732 [RFC5452] mandates the use of port randomization for DNS 733 resolvers, and mandates that implementations must randomize ports 734 from the range (53 or 1024, and above) or the largest possible 735 port range. It does not recommend possible algorithms for port 736 randomization, although the document specifically targets DNS 737 resolvers, for which a simple port randomization suffices (e.g. 738 Algorithm 1 of [RFC6056]). This document led to the 739 implementation of port randomization in the DNS resolver 740 themselves, rather than in the underlying transport-protocols. 742 January 2011: 743 [RFC6056] notes that many TCP and UDP implementations result in 744 predictable port numbers, and also notes that many implementations 745 select port numbers from a small portion of the whole port number 746 space. It recommends the implementation and use of ephemeral port 747 randomization, proposes a number of possible algorithms for port 748 randomization, and also recommends to randomize port numbers over 749 the range 1024-65535. 751 March 2016: 752 [NIST-NTP] reports a non-normal distribution of the ephemeral port 753 numbers employed by the NTP clients of an Internet Time Service. 755 April 2019: 756 [I-D.gont-ntp-port-randomization] notes that some NTP 757 implementations employ the NTP service port (123) as the local 758 port for non-symmetric modes, and aims to update the NTP 759 specification to recommend port randomization in such cases, in 760 line with [RFC6056]. The proposal experiences some push-back in 761 the relevant working group (NTP WG) [NTP-PORTR], but is finally 762 adopted as a working group item as 763 [I-D.ietf-ntp-port-randomization]. 765 August 2021: 766 [I-D.ietf-ntp-port-randomization] is finally published as 767 [RFC9109]. 769 5. Conclusions 771 For more than 30 years, a large number of implementations of the TCP/ 772 IP protocol suite have been subject to a variety of attacks, with 773 effects ranging from Denial of Service (DoS) or data injection, to 774 information leakages that could be exploited for pervasive monitoring 775 [RFC7258]. The root cause of these issues has been, in many cases, 776 poor selection of transient numeric identifiers, usually as a result 777 of insufficient or misleading specifications. 779 While it is generally possible to identify an algorithm that can 780 satisfy the interoperability requirements for a given transient 781 numeric identifier, this document provides empirical evidence that 782 doing so without negatively affecting the security or privacy 783 properties of the aforementioned protocols is non-trivial. It is 784 thus evident that advice in this area is warranted. 786 [I-D.gont-numeric-ids-sec-considerations] aims at requiring future 787 protocol specifications to contain analysis of the security and 788 privacy properties of any transient numeric identifiers specified by 789 the protocol, and to recommend an algorithm for the generation of 790 such transient numeric identifiers. 791 [I-D.irtf-pearg-numeric-ids-generation] specifies a number of sample 792 algorithms for generating transient numeric identifiers with specific 793 interorability requirements and failure severities. 795 6. IANA Considerations 797 There are no IANA registries within this document. The RFC-Editor 798 can remove this section before publication of this document as an 799 RFC. 801 7. Security Considerations 803 This document analyzes the timeline of the specification and 804 implementation of the transient numeric identifiers of some sample 805 IETF protocols, and how the security and privacy properties of such 806 protocols have been affected as a result of it. It provides concrete 807 evidence that advice in this area is warranted. 809 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol 810 specifications to specify the interoperability requirements for their 811 transient numeric identifiers, to do a warranted vulnerability 812 assessment of such transient numeric identifiers, and to recommend 813 possible algorithms for their generation, such that the 814 interoperability requirements are complied with, while any negative 815 security and privacy properties of these transient numeric 816 identifiers are mitigated. 818 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes 819 transient numeric identifiers based on their interoperability 820 requirements and their associated failure severities, and recommends 821 possible algorithms that can comply with those requirements without 822 negatively affecting the security and privacy properties of the 823 corresponding protocols. 825 8. Acknowledgements 827 The authors would like to thank (in alphabetical order) Bernard 828 Aboba, Dave Crocker, Theo de Raadt, Sara Dickinson, Guillermo Gont, 829 Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe 830 Touch, and Christopher Wood, for providing valuable comments on 831 earlier versions of this document. 833 The authors would like to thank (in alphabetical order) Steven 834 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 835 providing valuable comments on [I-D.gont-predictable-numeric-ids], on 836 which this document is based. 838 Section 4.2 of this document borrows text from [RFC6528], authored by 839 Fernando Gont and Steven Bellovin. 841 The authors would like to thank Sara Dickinson and Christopher Wood, 842 for their guidance during the publication process of this document. 844 The authors would like to thank Diego Armando Maradona for his magic 845 and inspiration. 847 9. References 848 9.1. Normative References 850 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 851 DOI 10.17487/RFC0768, August 1980, 852 . 854 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 855 RFC 793, DOI 10.17487/RFC0793, September 1981, 856 . 858 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 859 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 860 2012, . 862 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 863 DOI 10.17487/RFC0791, September 1981, 864 . 866 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 867 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, 868 December 1995, . 870 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 871 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 872 December 1998, . 874 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 875 (IPv6) Specification", STD 86, RFC 8200, 876 DOI 10.17487/RFC8200, July 2017, 877 . 879 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 880 Interface Identifiers with IPv6 Stateless Address 881 Autoconfiguration (SLAAC)", RFC 7217, 882 DOI 10.17487/RFC7217, April 2014, 883 . 885 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 886 Stateless Address Autoconfiguration in IPv6", RFC 3041, 887 DOI 10.17487/RFC3041, January 2001, 888 . 890 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. 891 Postel, "An IPv6 Provider-Based Unicast Address Format", 892 RFC 2073, DOI 10.17487/RFC2073, January 1997, 893 . 895 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 896 Aggregatable Global Unicast Address Format", RFC 2374, 897 DOI 10.17487/RFC2374, July 1998, 898 . 900 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 901 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 902 August 2003, . 904 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 905 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 906 December 1995, . 908 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 909 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 910 2006, . 912 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 913 Extensions for Stateless Address Autoconfiguration in 914 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 915 . 917 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 918 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 919 . 921 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 922 Address Autoconfiguration", RFC 4862, 923 DOI 10.17487/RFC4862, September 2007, 924 . 926 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 927 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 928 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 929 RFC 8415, DOI 10.17487/RFC8415, November 2018, 930 . 932 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 933 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 934 1992, . 936 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 937 Protocol Port Randomization", BCP 156, RFC 6056, 938 DOI 10.17487/RFC6056, January 2011, 939 . 941 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 942 Resilient against Forged Answers", RFC 5452, 943 DOI 10.17487/RFC5452, January 2009, 944 . 946 9.2. Informative References 948 [OpenBSD-PR] 949 OpenBSD, "Implementation of port randomization", 29 July 950 1996, . 953 [VU-800113] 954 CERT/CC, "Multiple DNS implementations vulnerable to cache 955 poisoning (Vulnerability Note VU#800113)", 8 July 2008, 956 . 958 [IANA-PROT] 959 IANA, "Protocol Registries", 960 . 962 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 963 RFC 5157, DOI 10.17487/RFC5157, March 2008, 964 . 966 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 967 "Temporary Address Extensions for Stateless Address 968 Autoconfiguration in IPv6", RFC 8981, 969 DOI 10.17487/RFC8981, February 2021, 970 . 972 [I-D.ietf-6man-rfc4941bis] 973 Gont, F., Krishnan, S., Narten, T., and R. Draves, 974 "Temporary Address Extensions for Stateless Address 975 Autoconfiguration in IPv6", Work in Progress, Internet- 976 Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020, 977 . 980 [I-D.gont-opsec-ipv6-host-scanning] 981 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 982 Networks", Work in Progress, Internet-Draft, draft-gont- 983 opsec-ipv6-host-scanning-02, 22 October 2012, 984 . 987 [I-D.ietf-opsec-ipv6-host-scanning] 988 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 989 Networks", Work in Progress, Internet-Draft, draft-ietf- 990 opsec-ipv6-host-scanning-08, 28 August 2015, 991 . 994 [I-D.gont-6man-stable-privacy-addresses] 995 Gont, F., "A method for Generating Stable Privacy-Enhanced 996 Addresses with IPv6 Stateless Address Autoconfiguration 997 (SLAAC)", Work in Progress, Internet-Draft, draft-gont- 998 6man-stable-privacy-addresses-01, 31 March 2012, 999 . 1002 [I-D.ietf-6man-stable-privacy-addresses] 1003 Gont, F., "A Method for Generating Semantically Opaque 1004 Interface Identifiers with IPv6 Stateless Address 1005 Autoconfiguration (SLAAC)", Work in Progress, Internet- 1006 Draft, draft-ietf-6man-stable-privacy-addresses-17, 27 1007 January 2014, . 1010 [I-D.cooper-6man-ipv6-address-generation-privacy] 1011 Cooper, A., Gont, F., and D. Thaler, "Privacy 1012 Considerations for IPv6 Address Generation Mechanisms", 1013 Work in Progress, Internet-Draft, draft-cooper-6man-ipv6- 1014 address-generation-privacy-00, 15 July 2013, 1015 . 1018 [I-D.ietf-6man-ipv6-address-generation-privacy] 1019 Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1020 Considerations for IPv6 Address Generation Mechanisms", 1021 Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- 1022 address-generation-privacy-08, 23 September 2015, 1023 . 1026 [Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit 1027 (help wanted!)", Message posted to the IPv6 Hackers 1028 mailing-list Message-ID: 1029 <51184548.3030105@si6networks.com>, 2013, 1030 . 1033 [IPv6-Toolkit] 1034 SI6 Networks, "SI6 Networks' IPv6 Toolkit", 1035 . 1037 [draft-gont-6man-stable-privacy-addresses-00] 1038 Gont, F., "A method for Generating Stable Privacy-Enhanced 1039 Addresses with IPv6 Stateless Address Autoconfiguration 1040 (SLAAC)", Work in Progress, Internet-Draft, draft-gont- 1041 6man-stable-privacy-addresses-00, 15 December 2011, 1042 . 1045 [draft-ietf-6man-stable-privacy-addresses-00] 1046 Gont, F., "A method for Generating Stable Privacy-Enhanced 1047 Addresses with IPv6 Stateless Address Autoconfiguration 1048 (SLAAC)", Work in Progress, Internet-Draft, draft-ietf- 1049 6man-stable-privacy-addresses-00, 18 May 2012, 1050 . 1053 [draft-gont-6man-address-usage-recommendations-00] 1054 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", 1055 Work in Progress, Internet-Draft, draft-gont-6man-address- 1056 usage-recommendations-00, 27 May 2016, 1057 . 1060 [draft-gont-6man-non-stable-iids-00] 1061 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 1062 Interface Identifiers", Work in Progress, Internet-Draft, 1063 draft-gont-6man-non-stable-iids-00, 23 May 2016, 1064 . 1067 [draft-ietf-6man-default-iids-00] 1068 Gont, F., Cooper, A., Thaler, D., and W. Liu, 1069 "Recommendation on Stable IPv6 Interface Identifiers", 1070 Work in Progress, Internet-Draft, draft-ietf-6man-default- 1071 iids-00, 28 July 2014, . 1074 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1075 "Recommendation on Stable IPv6 Interface Identifiers", 1076 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1077 . 1079 [draft-ietf-6man-rfc4941bis-00] 1080 Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves, 1081 "Privacy Extensions for Stateless Address 1082 Autoconfiguration in IPv6", Work in Progress, Internet- 1083 Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018, 1084 . 1087 [draft-fgont-6man-rfc4941bis-00] 1088 Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves, 1089 "Privacy Extensions for Stateless Address 1090 Autoconfiguration in IPv6", Work in Progress, Internet- 1091 Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018, 1092 . 1095 [I-D.ietf-6man-default-iids] 1096 Gont, F., Cooper, A., Thaler, D., and W. Liu, 1097 "Recommendation on Stable IPv6 Interface Identifiers", 1098 Work in Progress, Internet-Draft, draft-ietf-6man-default- 1099 iids-16, 28 September 2016, 1100 . 1103 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1104 Considerations for IPv6 Address Generation Mechanisms", 1105 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1106 . 1108 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1109 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1110 . 1112 [I-D.gont-predictable-numeric-ids] 1113 Gont, F. and I. Arce, "Security and Privacy Implications 1114 of Numeric Identifiers Employed in Network Protocols", 1115 Work in Progress, Internet-Draft, draft-gont-predictable- 1116 numeric-ids-03, 11 March 2019, 1117 . 1120 [I-D.gont-numeric-ids-sec-considerations] 1121 Gont, F. and I. Arce, "Security Considerations for 1122 Transient Numeric Identifiers Employed in Network 1123 Protocols", Work in Progress, Internet-Draft, draft-gont- 1124 numeric-ids-sec-considerations-06, 5 December 2020, 1125 . 1128 [I-D.irtf-pearg-numeric-ids-generation] 1129 Gont, F. and I. Arce, "On the Generation of Transient 1130 Numeric Identifiers", Work in Progress, Internet-Draft, 1131 draft-irtf-pearg-numeric-ids-generation-07, 2 February 1132 2021, . 1135 [I-D.ietf-6man-rfc2460bis] 1136 <>, S. E. D. and R. M. Hinden, "Internet Protocol, Version 1137 6 (IPv6) Specification", Work in Progress, Internet-Draft, 1138 draft-ietf-6man-rfc2460bis-13, 19 May 2017, 1139 . 1142 [draft-stenn-ntp-not-you-refid-00] 1143 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 1144 REFID", Work in Progress, Internet-Draft, draft-stenn-ntp- 1145 not-you-refid-00, 8 July 2016, . 1148 [draft-ietf-ntp-refid-updates-00] 1149 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 1150 REFID", Work in Progress, Internet-Draft, draft-ietf-ntp- 1151 refid-updates-00, 13 November 2016, 1152 . 1155 [Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- 1156 05", Post to the NTP WG mailing list Message-ID: 1157 , 16 1158 April 2019, . 1161 [I-D.ietf-ntp-refid-updates] 1162 Stenn, H. and S. Goldberg, "Network Time Protocol REFID 1163 Updates", Work in Progress, Internet-Draft, draft-ietf- 1164 ntp-refid-updates-05, 25 March 2019, 1165 . 1168 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1169 "Network Time Protocol Version 4: Protocol and Algorithms 1170 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1171 . 1173 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1174 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1175 2014, . 1177 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1178 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1179 . 1181 [Wright1994] 1182 Wright, G.R. and W.R. Stevens, "TCP/IP Illustrated, Volume 1183 2: The Implementation", Addison-Wesley, 1994. 1185 [Zalewski2001] 1186 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1187 Number Analysis", 2001, 1188 . 1190 [Zalewski2002] 1191 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1192 Number Analysis - One Year Later", 2001, 1193 . 1195 [Bellovin1989] 1196 Bellovin, S., "Security Problems in the TCP/IP Protocol 1197 Suite", Computer Communications Review, vol. 19, no. 2, 1198 pp. 32-48, 1989, 1199 . 1201 [Morris1985] 1202 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1203 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1204 NJ, 1985, 1205 . 1207 [USCERT2001] 1208 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 1209 TCP/IP implementations may use statistically predictable 1210 initial sequence numbers", 2001, 1211 . 1213 [CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 1214 TCP/IP Initial Sequence Numbers", 2001, 1215 . 1218 [Shimomura1995] 1219 Shimomura, T., "Technical details of the attack described 1220 by Markoff in NYT", Message posted in USENET's 1221 comp.security.misc newsgroup Message-ID: 1222 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1223 . 1225 [I-D.eddy-rfc793bis-04] 1226 Eddy, W., "Transmission Control Protocol Specification", 1227 Work in Progress, Internet-Draft, draft-eddy-rfc793bis-04, 1228 25 August 2014, 1229 . 1231 [OpenBSD-TCP-ISN-I] 1232 OpenBSD, "Implementation of TCP ISN randomization based on 1233 random increments", 29 July 1996, 1234 . 1237 [OpenBSD-TCP-ISN-R] 1238 OpenBSD, "Implementation of TCP ISN randomization based on 1239 simple randomization", 13 December 2000, 1240 . 1243 [OpenBSD-TCP-ISN-H] 1244 OpenBSD, "Implementation of RFC1948 for TCP ISN 1245 randomization", 13 December 2000, 1246 . 1249 [I-D.gont-ntp-port-randomization] 1250 Gont, F. and G. Gont, "Port Randomization in the Network 1251 Time Protocol Version 4", Work in Progress, Internet- 1252 Draft, draft-gont-ntp-port-randomization-04, 6 August 1253 2019, . 1256 [I-D.ietf-ntp-port-randomization] 1257 Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol 1258 Version 4: Port Randomization", Work in Progress, 1259 Internet-Draft, draft-ietf-ntp-port-randomization-08, 10 1260 June 2021, . 1263 [RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol 1264 Version 4: Port Randomization", RFC 9109, 1265 DOI 10.17487/RFC9109, August 2021, 1266 . 1268 [NTP-PORTR] 1269 Gont, F., "[Ntp] New rev of the NTP port randomization I-D 1270 (Fwd: New Version Notification for draft-gont-ntp-port- 1271 randomization-01.txt)", 2019, 1272 . 1275 [NIST-NTP] Sherman, J.A. and J. Levine, "Usage Analysis of the NIST 1276 Internet Time Service", Journal of Research of the 1277 National Institute of Standards and Technology Volume 121, 1278 8 March 2016, . 1280 [IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and 1281 KASLR Bypass (Extended Version)", June 2019, 1282 . 1284 [RFC1035] Mockapetris, P., "Domain names - implementation and 1285 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1286 November 1987, . 1288 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1289 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 1290 . 1292 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1293 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1294 February 2016, . 1296 [Bellovin2002] 1297 Bellovin, S. M., "A Technique for Counting NATted Hosts", 1298 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002, 1299 . 1301 [Fyodor2002] 1302 Fyodor, "Idle scanning and related IP ID games", 2002, 1303 . 1305 [Sanfilippo1998a] 1306 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1307 mailing-list, Mon Dec 14 1998, 1308 . 1310 [Sanfilippo1998b] 1311 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1312 1998, . 1315 [Sanfilippo1999] 1316 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1317 list, 1999, 1318 . 1321 [Morbitzer2013] 1322 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message 1323 posted to the nmap-dev mailing-list, 2013, 1324 . 1326 [OpenBSD-IPv4-ID] 1327 OpenBSD, "Randomization of the IPv4 Identification field", 1328 26 December 1998, 1329 . 1332 [OpenBSD-IPv6-ID] 1333 OpenBSD, "Randomization of the IPv6 Identification field", 1334 1 October 2003, 1335 . 1338 [Silbersack2005] 1339 Silbersack, M.J., "Improving TCP/IP security through 1340 randomization without sacrificing interoperability", 1341 EuroBSDCon 2005 Conference, 2005, 1342 . 1345 [Zalewski2003] 1346 Zalewski, M., "A new TCP/IP blind data injection 1347 technique?", 2003, 1348 . 1350 [Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and 1351 Solutions", 1997, 1352 . 1354 [Klein2007] 1355 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 1356 Predictable IP ID Vulnerability", 2007, 1357 . 1361 [Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack 1362 In Paris 2011 Conference Paris, France, June 2011. 1364 [RedHat2011] 1365 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 1366 Important: kernel security and bug fix update", 2011, 1367 . 1369 [Ubuntu2011] 1370 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 1371 vulnerabilities", 2011, 1372 . 1374 [SUSE2011] SUSE, "SUSE Security Announcement: Linux kernel security 1375 update (SUSE-SA:2011:046)", 2011, 1376 . 1379 [Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 1380 Conference Ottawa, Canada. May 11-12, 2012, May 2012, 1381 . 1385 [I-D.gont-6man-predictable-fragment-id] 1386 Gont, F., "Security Implications of Predictable Fragment 1387 Identification Values", Work in Progress, Internet-Draft, 1388 draft-gont-6man-predictable-fragment-id-03, 9 January 1389 2013, . 1392 [I-D.ietf-6man-predictable-fragment-id] 1393 Gont, F., "Security Implications of Predictable Fragment 1394 Identification Values", Work in Progress, Internet-Draft, 1395 draft-ietf-6man-predictable-fragment-id-10, 9 October 1396 2015, . 1399 [draft-ietf-6man-predictable-fragment-id-01] 1400 Gont, F., "Security Implications of Predictable Fragment 1401 Identification Values", Work in Progress, Internet-Draft, 1402 draft-ietf-6man-predictable-fragment-id-01, 30 April 2014, 1403 . 1406 [draft-ietf-6man-predictable-fragment-id-02] 1407 Gont, F., "Security Implications of Predictable Fragment 1408 Identification Values", Work in Progress, Internet-Draft, 1409 draft-ietf-6man-predictable-fragment-id-02, 19 December 1410 2014, . 1413 [draft-gont-6man-predictable-fragment-id-00] 1414 Gont, F., "Security Implications of Predictable Fragment 1415 Identification Values", Work in Progress, Internet-Draft, 1416 draft-gont-6man-predictable-fragment-id-00, 15 December 1417 2011, . 1420 [draft-ietf-6man-predictable-fragment-id-00] 1421 Gont, F., "Security Implications of Predictable Fragment 1422 Identification Values", Work in Progress, Internet-Draft, 1423 draft-ietf-6man-predictable-fragment-id-00, 22 March 2013, 1424 . 1427 [draft-ietf-6man-predictable-fragment-id-08] 1428 Gont, F., "Security Implications of Predictable Fragment 1429 Identification Values", Work in Progress, Internet-Draft, 1430 draft-ietf-6man-predictable-fragment-id-08, 9 June 2015, 1431 . 1434 Authors' Addresses 1436 Fernando Gont 1437 EdgeUno 1438 Segurola y Habana 4310 7mo piso 1439 Ciudad Autonoma de Buenos Aires 1440 Buenos Aires 1441 Argentina 1443 Email: fernando.gont@edgeuno.com 1444 URI: https://www.edgeuno.com 1446 Ivan Arce 1447 Quarkslab 1448 Segurola y Habana 4310 7mo piso 1449 Ciudad Autonoma de Buenos Aires 1450 Buenos Aires 1451 Argentina 1453 Email: iarce@quarkslab.com 1454 URI: https://www.quarkslab.com