idnits 2.17.1 draft-irtf-pearg-numeric-ids-history-07.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 (February 2, 2021) is 1173 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 (-13) exists of draft-ietf-6man-rfc2460bis-12 == 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-06 -- 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 (~~), 6 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: August 6, 2021 Quarkslab 6 February 2, 2021 8 Unfortunate History of Transient Numeric Identifiers 9 draft-irtf-pearg-numeric-ids-history-07 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 August 6, 2021. 38 Copyright Notice 40 Copyright (c) 2021 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Issues with the Specification of Transient Numeric 56 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 5 58 6. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 9 59 7. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 11 60 8. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . . . 14 61 9. Transport Protocol Ephemeral Port Numbers . . . . . . . . . . 14 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 63 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 64 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 67 13.2. Informative References . . . . . . . . . . . . . . . . . 19 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 95 [Sanfilippo1998a], [RFC6274], and [RFC7739]) 97 o Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and 98 [RFC7217]) 100 o Predictable transport protocol ephemeral port numbers (see e.g. 101 [RFC6056] and [Silbersack2005]) 103 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. 104 [Morris1985], [Bellovin1989], and [RFC6528]) 106 o Predictable DNS TxIDs (see e.g. [Schuba1993] 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 o Vulnerabilities associated with the inappropriate generation of 122 transient numeric identifiers have affected protocol 123 implementations for an extremely long period of time. 125 o 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 o 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 170 cannot observe the packets being transferred between the sender and 171 the receiver(s) of the target protocol (if any). However, we assume 172 the attacker can send any traffic to the target device(s), to e.g. 173 sample transient numeric identifiers employed by such device(s). 175 4. Issues with the Specification of Transient Numeric Identifiers 177 While assessing protocol specifications regarding the use of 178 transient numeric identifiers, we have found that most of the issues 179 discussed in this document arise as a result of one of the following 180 conditions: 182 o Protocol specifications that under-specify the requirements for 183 their transient numeric identifiers 185 o Protocol specifications that over-specify their transient numeric 186 identifiers 188 o Protocol implementations that simply fail to comply with the 189 specified requirements 191 A number of protocol specifications (too many of them) have simply 192 overlooked the security and privacy implications of transient numeric 193 identifiers. Examples of them are the specification of TCP ephemeral 194 ports in [RFC0793], the specification of TCP sequence numbers in 195 [RFC0793], or the specification of the DNS TxID in [RFC1035]. 197 On the other hand, there are a number of protocol specifications that 198 over-specify some of their associated transient numeric identifiers. 199 For example, [RFC4291] essentially overloads the semantics of IPv6 200 Interface Identifiers (IIDs) by embedding link-layer addresses in the 201 IPv6 IIDs, when the interoperability requirement of uniqueness could 202 be achieved in other ways that do not result in negative security and 203 privacy implications [RFC7721]. Similarly, [RFC2460] suggested the 204 use of a global counter for the generation of Fragment Identification 205 values, when the interoperability properties of uniqueness per {Src 206 IP, Dst IP} could be achieved with other algorithms that do not 207 result in negative security and privacy implications [RFC7739]. 209 Finally, there are protocol implementations that simply fail to 210 comply with existing protocol specifications. For example, some 211 popular operating systems (notably Microsoft Windows) still fail to 212 implement transport protocol ephemeral port randomization, as 213 recommended in [RFC6056]. 215 5. IPv4/IPv6 Identification 217 This section presents the timeline of the Identification field 218 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). 219 The reason for presenting both cases in the same section is to make 220 it evident that while the Identification value serves the same 221 purpose in both IPv4 and IPv6, the work and research done for the 222 IPv4 case did not affect IPv6 specifications or implementations. 224 The IPv4 Identification is specified in [RFC0791], which specifies 225 the interoperability requirements for the Identification field: the 226 sender must choose the Identification field to be unique for a given 227 source address, destination address, and protocol, for the time the 228 datagram (or any fragment of it) could be alive in the internet. It 229 suggests that a node may keep "a table of Identifiers, one entry for 230 each destination it has communicated with in the last maximum packet 231 lifetime for the internet", and suggests that "since the Identifier 232 field allows 65,536 different values, hosts may be able to simply use 233 unique identifiers independent of destination". The above has been 234 interpreted numerous times as a suggestion to employ per-destination 235 or global counters for the generation of Identification values. 236 While [RFC0791] does not suggest any flawed algorithm for the 237 generation of Identification values, the specification omits a 238 discussion of the security and privacy implications of predictable 239 Identification values. This has resulted in many IPv4 240 implementations generating predictable fragment Identification values 241 by means of a global counter, at least at some point in time. 243 The IPv6 Identification was originally specified in [RFC1883]. It 244 serves the same purpose as its IPv4 counterpart, with the only 245 difference residing in the length of the corresponding field, and 246 that while the IPv4 Identification field is part of the base IPv4 247 header, in the IPv6 case it is part of the Fragment header (which may 248 or may not be present in an IPv6 packet). [RFC1883] states, in 249 Section 4.5, that the Identification must be different than that of 250 any other fragmented packet sent recently (within the maximum likely 251 lifetime of a packet) with the same Source Address and Destination 252 Address. Subsequently, it notes that this requirement can be met by 253 means of a wrap-around 32-bit counter that is incremented each time a 254 packet must be fragmented, and that it is an implementation choice 255 whether to use a global or a per-destination counter. Thus, the 256 implementation of the IPv6 Identification is similar to that of the 257 IPv4 case, with the only difference that in the IPv6 case the 258 suggestions to use simple counters is more explicit. [RFC2460] was 259 the first revision of the core IPv6 specification, and maintained the 260 same text for the specification of the IPv6 Identification field. 261 [RFC8200], the second revision of the core IPv6 specification, 262 removes the suggestion from [RFC2460] to use a counter for the 263 generation of IPv6 Identification values, and points to [RFC7739] for 264 sample algorithms for their generation. 266 September 1981: 267 [RFC0791] specifies the interoperability requirements for IPv4 268 Identification value, but does not perform a vulnerability 269 assessment of this transient numeric identifier. 271 December 1995: 272 [RFC1883], the first specification of the IPv6 protocol, is 273 published. It suggests that a counter be used to generate the 274 IPv6 Identification value, and notes that it is an implementation 275 choice whether to maintain a single counter for the node or 276 multiple counters, e.g., one for each of the node's possible 277 source addresses, or one for each active (source address, 278 destination address) combination. 280 December 1998: 281 [Sanfilippo1998a] finds that predictable IPv4 Identification 282 values (generated by most popular implementations) can be 283 leveraged to count the number of packets sent by a target node. 284 [Sanfilippo1998b] explains how to leverage the same vulnerability 285 to implement a port-scanning technique known as dumb/idle scan. A 286 tool that implements this attack is publicly released. 288 December 1998: 289 [RFC2460], a revision of the IPv6 specification, is published, 290 obsoleting [RFC1883]. It maintains the same specification of the 291 IPv6 Identification field as its predecessor ([RFC1883]). 293 December 1998: 294 OpenBSD implements randomization of the IPv4 Identification field 295 [OpenBSD-IPv4-ID]. 297 November 1999: 298 [Sanfilippo1999] discusses how to leverage predictable IPv4 299 Identification to uncover the rules of a number of firewalls. 301 November 1999: 302 [Bellovin2002] explains how the IPv4 Identification field can be 303 exploited to count the number of systems behind a NAT. 305 September 2002: 306 [Fyodor2002] explains how to implement a stealth port-scanning 307 technique by leveraging nodes that employ predictable IPv4 308 Identification values. 310 October 2003: 311 OpenBSD implements randomization of the IPv6 Identification field 312 [OpenBSD-IPv6-ID]. 314 December 2003: 315 [Zalewski2003] explains a technique to perform TCP data injection 316 attack based on predictable IPv4 identification values which 317 requires less effort than TCP injection attacks performed with 318 bare TCP packets. 320 November 2005: 321 [Silbersack2005] discusses shortcoming in a number of techniques 322 to mitigate predictable IPv4 Identification values. 324 October 2007: 325 [Klein2007] describes a weakness in the pseudo random number 326 generator (PRNG) in use for the generation of the IP 327 Identification by a number of operating systems. 329 June 2011: 330 [Gont2011] describes how to perform idle scan attacks in IPv6. 332 November 2011: 333 Linux mitigates predictable IPv6 Identification values 334 [RedHat2011] [SUSE2011] [Ubuntu2011]. 336 December 2011: 337 [draft-gont-6man-predictable-fragment-id-00] describes the 338 security implications of predictable IPv6 Identification values, 339 and possible mitigations. This document has the Intended Status 340 of "Standards Track", with the intention to formally update 341 [RFC2460], to introduce security and privacy requirements on IPv6 342 Identification values. 344 May 2012: 345 [Gont2012] notes that some major IPv6 implementations still employ 346 predictable IPv6 Identification values. 348 March 2013: 349 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but 350 changes the track to "BCP" (while still formally updating 351 [RFC2460]), publishing the resulting document as 352 [draft-ietf-6man-predictable-fragment-id-00]. 354 June 2013: 355 A patch that implements IPv6-based idle-scan in nmap is submitted 356 [Morbitzer2013]. 358 December 2014: 359 The 6man WG changes the Intended Status of 360 [draft-ietf-6man-predictable-fragment-id-01] to "Informational" 361 and publishes it as [draft-ietf-6man-predictable-fragment-id-02]. 362 As a result, it no longer formally updates [RFC2460]. 364 June 2015: 365 [draft-ietf-6man-predictable-fragment-id-08] notes that some 366 popular host and router implementations still employ predictable 367 IPv6 Identification values. 369 February 2016: 370 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) 371 analyzes the security and privacy implications of predictable IPv6 372 Identification values, and provides guidance for selecting an 373 algorithm to generate such values. However, being published with 374 the Intended Status of "Informational", it does not formally 375 update [RFC2460]. 377 June 2016: 378 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the 379 suggestion from RFC2460 to use a counter for the generation of 380 IPv6 Identification values, but does not perform a vulnerability 381 assessment of the generation of IPv6 Identification values. 383 July 2017: 385 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], 386 obsoleting [RFC2460], and pointing to [RFC7739] for sample 387 algorithms for the generation of IPv6 Fragment Identification 388 values. 390 June 2019: 391 [IPID-DEV] notes that the IPv6 ID generators of two popular 392 operating systems are flawed. 394 6. TCP Initial Sequence Numbers (ISNs) 396 [RFC0793] suggests that the choice of the ISN of a connection is not 397 arbitrary, but aims to reduce the chances of a stale segment from 398 being accepted by a new incarnation of a previous connection. 399 [RFC0793] suggests the use of a global 32-bit ISN generator that is 400 incremented by 1 roughly every 4 microseconds. However, as a matter 401 of fact, protection against stale segments from a previous 402 incarnation of the connection is enforced by preventing the creation 403 of a new incarnation of a previous connection before 2*MSL have 404 passed since a segment corresponding to the old incarnation was last 405 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This 406 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept 407 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are 408 monotonically increasing across connections, many stacks (e.g., 409 4.2BSD-derived) use the ISN of an incoming SYN segment to perform 410 "heuristics" that enable the creation of a new incarnation of a 411 connection while the previous incarnation is still in the TIME-WAIT 412 state (see p. 945 of [Wright1994]). This avoids an interoperability 413 problem that may arise when a node establishes connections to a 414 specific TCP end-point at a high rate [Silbersack2005]. 416 The interoperability requirements for TCP ISNs are probably not as 417 clearly spelled out as one would expect. Furthermore, the suggestion 418 of employing a global counter in [RFC0793] negatively affects the 419 security and privacy properties of the protocol. 421 September 1981: 422 [RFC0793], suggests the use of a global 32-bit ISN generator, 423 whose lower bit is incremented roughly every 4 microseconds. 424 However, such an ISN generator makes it trivial to predict the ISN 425 that a TCP instance will use for new connections, thus allowing a 426 variety of attacks against TCP. 428 February 1985: 429 [Morris1985] was the first to describe how to exploit predictable 430 TCP ISNs for forging TCP connections that could then be leveraged 431 for trust relationship exploitation. 433 April 1989: 434 [Bellovin1989] discussed the security considerations for 435 predictable ISNs (along with a range of other protocol-based 436 vulnerabilities). 438 February 1995: 439 [Shimomura1995] reported a real-world exploitation of the attack 440 described in 1985 (ten years before) in [Morris1985]. 442 May 1996: 443 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 444 to address predictable TCP ISNs. The same concept specified in 445 this document for TCP ISNs was later proposed for TCP ephemeral 446 ports [RFC6056], TCP Timestamps, and eventually even IPv6 447 Interface Identifiers [RFC7217]. 449 July 1996: 450 OpenBSD implements TCP ISN randomization based on random 451 increments (please see Appendix A.2 of 452 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I]. 454 December 2000: 455 OpenBSD implements TCP ISN randomization using simple 456 randomization (please see Section 7.1 of 457 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R]. 459 March 2001: 460 [Zalewski2001] provides a detailed analysis of statistical 461 weaknesses in some ISN generators, and includes a survey of the 462 algorithms in use by popular TCP implementations. 464 May 2001: 465 Vulnerability advisories [CERT2001] [USCERT2001] are released 466 regarding statistical weaknesses in some ISN generators, affecting 467 popular TCP/IP implementations. 469 March 2002: 470 [Zalewski2002] updates and complements [Zalewski2001]. It 471 concludes that "while some vendors [...] reacted promptly and 472 tested their solutions properly, many still either ignored the 473 issue and never evaluated their implementations, or implemented a 474 flawed solution that apparently was not tested using a known 475 approach" [Zalewski2002]. 477 June 2007: 478 OpenBSD implements TCP ISN randomization based on the algorithm 479 specified in [RFC1948] (currently obsoleted by [RFC6528]) for the 480 TCP endpoint that performs the active open, while keeping the 481 simple randomization scheme for the endpoint performing the 482 passive open [OpenBSD-TCP-ISN-H]. This provides monotonically- 483 increasing ISNs for the client side (allowing the BSD heuristics 484 to work as expected), while avoiding any patterns in the ISN 485 generation for the server side. 487 February 2012: 488 [RFC6528], published 27 years after Morris' original work 489 [Morris1985], formally updates [RFC0793] to mitigate predictable 490 TCP ISNs. 492 August 2014: 493 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 494 protocol specification, incorporates the algorithm specified in 495 [RFC6528] as the recommended algorithm for TCP ISN generation. 497 7. IPv6 Interface Identifiers (IIDs) 499 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC 500 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section 501 focuses on Interface Identifiers resulting from SLAAC. 503 The Interface Identifier of stable (traditional) IPv6 addresses 504 resulting from SLAAC have traditionally resulted in the underlying 505 link-layer address being embedded in the IID. At the time, employing 506 the underlying link-layer address for the IID was seen as a 507 convenient way to obtain a unique address. However, recent awareness 508 about the security and privacy properties of this approach [RFC7707] 509 [RFC7721] has led to the replacement of this flawed scheme with an 510 alternative one [RFC7217] [RFC8064] that does not negatively affect 511 the security and privacy properties of the protocol. 513 January 1997: 514 [RFC2073] specifies the syntax of IPv6 global addresses (referred 515 to as "An IPv6 Provider-Based Unicast Address Format" at the 516 time), consistent with the IPv6 addressing architecture specified 517 in [RFC1884]. Hosts are recommended to "generate addresses using 518 link-specific addresses as Interface ID such as 48 bit IEEE-802 519 MAC addresses". 521 July 1998: 522 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address 523 Format" (obsoleting [RFC2373]) changing the size of the Interface 524 ID to 64 bits, and specifies that that IIDs must be constructed in 525 IEEE EUI-64 format. How such identifiers are constructed becomes 526 specified in the appropriate "IPv6 over " specification such 527 as "IPv6 over Ethernet". 529 January 2001: 530 [RFC3041] recognizes the problem of network activity correlation, 531 and specifies temporary addresses. Temporary addresses are to be 532 used along with stable addresses. 534 August 2003: 535 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure 536 historic. The syntax and recommendations for the traditional 537 stable IIDs remain unchanged, though. 539 February 2006: 540 [RFC4291] is published as the latest "IP Version 6 Addressing 541 Architecture", requiring the IIDs of the traditional (stable) 542 autoconfigured addresses to employ the Modified EUI-64 format. 543 The details of constructing such interface identifiers are defined 544 in the appropriate "IPv6 over " specifications. 546 March 2008: 547 [RFC5157] provides hints regarding how patterns in IPv6 addresses 548 could be leveraged for the purpose of address scanning. 550 December 2011: 551 [draft-gont-6man-stable-privacy-addresses-00] notes that the 552 traditional scheme for generating stable addresses allows for 553 address scanning, and also does not prevent active node tracking. 554 It also specifies an alternative algorithm meant to replace IIDs 555 based on Modified EUI-64 format identifiers. 557 November 2012: 558 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a 559 working group item (as 560 [draft-ietf-6man-stable-privacy-addresses-00]). However, the 561 document no longer formally updates [RFC4291], and therefore the 562 specified algorithm no longer formally replaces the Modified 563 EUI-64 format identifiers. 565 February 2013: 566 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages 567 IPv6 address patterns is released [Gont2013]. 569 July 2013: 570 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on 571 the security and privacy properties of all known algorithms for 572 generating IPv6 IIDs. 574 January 2014: 575 The 6man WG publishes [draft-ietf-6man-default-iids-00] 576 ("Recommendation on Stable IPv6 Interface Identifiers"), 577 recommending [I-D.ietf-6man-stable-privacy-addresses] for the 578 generation of stable addresses. 580 April 2014: 581 [RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) is 582 published, specifying "A Method for Generating Semantically Opaque 583 Interface Identifiers with IPv6 Stateless Address 584 Autoconfiguration (SLAAC)" as an alternative to (but *not* 585 replacement of) Modified EUI-64 format IIDs. 587 March 2016: 588 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], and later 589 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network 590 Reconnaissance in IPv6 Networks", is published. 592 March 2016: 593 [RFC7721] (formerly 594 [I-D.cooper-6man-ipv6-address-generation-privacy] and later 595 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security 596 and Privacy Considerations for IPv6 Address Generation 597 Mechanisms", is published. 599 May 2016: 600 [draft-gont-6man-non-stable-iids-00] is published, with the goal 601 of specifying requirements for non-stable addresses, and updating 602 [RFC4941] such that use of only temporary addresses is allowed. 604 May 2016: 605 [draft-gont-6man-address-usage-recommendations-00] is published, 606 providing an analysis of how different aspects on an address (from 607 stability to usage mode) affect their corresponding security and 608 privacy properties, and meaning to eventually provide advice in 609 this area. 611 February 2017: 612 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6 613 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), 614 with requirements for stable addresses and a recommendation to 615 employ [RFC7217] for the generation of stable addresses. It 616 formally updates a large number of RFCs. 618 March 2018: 619 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the 620 6man WG), to address flaws in [RFC4941] by revising it (as an 621 alternative to the [draft-gont-6man-non-stable-iids-00] effort, 622 published in March 2016). 624 July 2018: 626 [draft-ietf-6man-rfc4941bis-00] is adopted (as 627 [draft-fgont-6man-rfc4941bis-00]) as a WG item of the 6man WG. 629 March 2020: 630 [I-D.ietf-6man-rfc4941bis] passes WGLC. 632 December 2020: 633 [I-D.ietf-6man-rfc4941bis] is finally approved by the IESG for 634 publication as an RFC. 636 8. NTP Reference IDs (REFIDs) 638 NTP [RFC5905] Reference IDs are employed to avoid degree-one timing 639 loops in scenarios where two NTP peers are (mutually) the time source 640 of each other. 642 June 2010: 643 [RFC5905], "Network Time Protocol Version 4: Protocol and 644 Algorithms Specification" is published. It specifies that for NTP 645 peers with stratum higher than 1 the REFID embeds the IPv4 Address 646 of the time source or an MD5 hash of the IPv6 address of the time 647 source. 649 July 2016: 650 [draft-stenn-ntp-not-you-refid-00] is published, describing the 651 information leakage produced via the NTP REFID. It proposes that 652 NTP returns a special REFID when a packet employs an IP Source 653 Address that is not believed to be a current NTP peer, but 654 otherwise generates and returns the traditional REFID. It is 655 subsequently adopted by the NTP WG as 656 [I-D.ietf-ntp-refid-updates]. 658 April 2019: 659 [Gont-NTP] notes that the proposed fix specified in 660 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub- 661 optimal. 663 9. Transport Protocol Ephemeral Port Numbers 665 Most (if not all) transport protocols employ "port numbers" to 666 demultiplex packets to the corresponding transport protocol 667 instances. 669 August 1980: 670 [RFC0768] notes that the UDP source port is optional and 671 identifies the port of the sending process. It does not specify 672 interoperability requirements for source port selection, nor does 673 it suggest possible ways to select port numbers. Most popular 674 implementations end up selecting source ports from a system-wide 675 global counter. 677 September 1981: 678 [RFC0793] (the TCP specification) essentially describes the use of 679 port numbers, and specifies that port numbers should result in a 680 unique socket pair (local address, local port, remote address, 681 remote port). How ephemeral ports (i.e. port numbers for "active 682 opens") are selected, and the port range from which they are 683 selected, are left unspecified. 685 July 1996: 686 OpenBSD implements ephemeral port randomization [OpenBSD-PR]. 688 July 2008: 689 The CERT Coordination Centre published details of what became 690 known as the "Kaminsky Attack" [VU-800113] on the DNS. The attack 691 exploited the lack of source port randomization in many major DNS 692 implementations to perform cache poisoning in an effective and 693 practical manner. 695 January 2009: 696 [RFC5452] mandates the use of port randomization for DNS 697 resolvers, and mandates that implementations must randomize ports 698 from the range (53 or 1024, and above) or the largest possible 699 port range. It does not recommend possible algorithms for port 700 randomization, although the document specifically targets DNS 701 resolvers, for which a simple port randomization suffices (e.g. 702 Algorithm 1 of [RFC6056]). This document led to the 703 implementation of port randomization in the DNS resolver 704 themselves, rather than in the underlying transport-protocols. 706 January 2011: 707 [RFC6056] notes that many TCP and UDP implementations result in 708 predictable port numbers, and also notes that many implementations 709 select port numbers from a small portion of the whole port number 710 space. It recommends the implementation and use of ephemeral port 711 randomization, proposes a number of possible algorithms for port 712 randomization, and also recommends to randomize port numbers over 713 the range 1024-65535. 715 March 2016: 716 [NIST-NTP] reports a non-normal distribution of the ephemeral port 717 numbers employed by the NTP clients of an Internet Time Service. 719 April 2019: 720 [I-D.gont-ntp-port-randomization] notes that some NTP 721 implementations employ the NTP service port (123) as the local 722 port for non-symmetric modes, and aims to update the NTP 723 specification to recommend port randomization in such cases, in 724 line with [RFC6056]. The proposal experiences some push-back in 725 the relevant working group (NTP WG) [NTP-PORTR], but is finally 726 adopted as a working group item as 727 [I-D.ietf-ntp-port-randomization]. 729 September 2019: 730 [I-D.ietf-ntp-port-randomization] passes its WGLC. 732 10. IANA Considerations 734 There are no IANA registries within this document. The RFC-Editor 735 can remove this section before publication of this document as an 736 RFC. 738 11. Security Considerations 740 This document analyzes the timeline of the specification and 741 implementation of the transient numeric identifiers of some sample 742 IETF protocols, and how the security and privacy properties of such 743 protocols have been affected as a result of it. It provides concrete 744 evidence that advice in this area is warranted. 746 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol 747 specifications to specify the interoperability requirements for their 748 transient numeric identifiers, to do a warranted vulnerability 749 assessment of such transient numeric identifiers, and to recommend 750 possible algorithms for their generation, such that the 751 interoperability requirements are complied with, while any negative 752 security and privacy properties of these transient numeric 753 identifiers are mitigated. 755 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes 756 transient numeric identifiers based on their interoperability 757 requirements and their associated failure modes, and recommends 758 possible algorithms that can comply with those requirements without 759 negatively affecting the security and privacy properties of the 760 corresponding protocols. 762 12. Acknowledgements 764 The authors would like to thank (in alphabetical order) Bernard 765 Aboba, Dave Crocker, Theo de Raadt, Sara Dickinson, Guillermo Gont, 766 Christian Huitema, Kris Shrishak, Joe Touch, and Christopher Wood, 767 for providing valuable comments on earlier versions of this document. 769 The authors would like to thank (in alphabetical order) Steven 770 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 771 providing valuable comments on [I-D.gont-predictable-numeric-ids], on 772 which this document is based. 774 Section 6 of this document borrows text from [RFC6528], authored by 775 Fernando Gont and Steven Bellovin. 777 The authors would like to thank Sara Dickinson and Christopher Wood, 778 for their guidance during the publication process of this document. 780 The authors would like to thank Diego Armando Maradona for his magic 781 and inspiration. 783 13. References 785 13.1. Normative References 787 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 788 DOI 10.17487/RFC0768, August 1980, 789 . 791 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 792 DOI 10.17487/RFC0791, September 1981, 793 . 795 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 796 RFC 793, DOI 10.17487/RFC0793, September 1981, 797 . 799 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 800 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 801 1992, . 803 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 804 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, 805 December 1995, . 807 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 808 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 809 December 1995, . 811 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. 812 Postel, "An IPv6 Provider-Based Unicast Address Format", 813 RFC 2073, DOI 10.17487/RFC2073, January 1997, 814 . 816 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 817 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 818 . 820 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 821 Aggregatable Global Unicast Address Format", RFC 2374, 822 DOI 10.17487/RFC2374, July 1998, 823 . 825 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 826 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 827 December 1998, . 829 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 830 Stateless Address Autoconfiguration in IPv6", RFC 3041, 831 DOI 10.17487/RFC3041, January 2001, 832 . 834 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 835 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 836 August 2003, . 838 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 839 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 840 2006, . 842 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 843 Address Autoconfiguration", RFC 4862, 844 DOI 10.17487/RFC4862, September 2007, 845 . 847 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 848 Extensions for Stateless Address Autoconfiguration in 849 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 850 . 852 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 853 Resilient against Forged Answers", RFC 5452, 854 DOI 10.17487/RFC5452, January 2009, 855 . 857 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 858 Protocol Port Randomization", BCP 156, RFC 6056, 859 DOI 10.17487/RFC6056, January 2011, 860 . 862 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 863 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 864 2012, . 866 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 867 Interface Identifiers with IPv6 Stateless Address 868 Autoconfiguration (SLAAC)", RFC 7217, 869 DOI 10.17487/RFC7217, April 2014, 870 . 872 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 873 (IPv6) Specification", STD 86, RFC 8200, 874 DOI 10.17487/RFC8200, July 2017, 875 . 877 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 878 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 879 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 880 RFC 8415, DOI 10.17487/RFC8415, November 2018, 881 . 883 13.2. Informative References 885 [Bellovin1989] 886 Bellovin, S., "Security Problems in the TCP/IP Protocol 887 Suite", Computer Communications Review, vol. 19, no. 2, 888 pp. 32-48, 1989, 889 . 891 [Bellovin2002] 892 Bellovin, S., "A Technique for Counting NATted Hosts", 893 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002, 894 . 896 [CERT2001] 897 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 898 TCP/IP Initial Sequence Numbers", 2001, 899 . 902 [draft-fgont-6man-rfc4941bis-00] 903 Gont, F., Krishnan, S., Narten, T., and R. Draves, 904 "Privacy Extensions for Stateless Address 905 Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00 906 (work in progress), March 2018. 908 [draft-gont-6man-address-usage-recommendations-00] 909 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", 910 draft-gont-6man-address-usage-recommendations-00 (work in 911 progress), May 2016. 913 [draft-gont-6man-non-stable-iids-00] 914 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 915 Interface Identifiers", draft-gont-6man-non-stable-iids-00 916 (work in progress), May 2016. 918 [draft-gont-6man-predictable-fragment-id-00] 919 Gont, F., "Security Implications of Predictable Fragment 920 Identification Values", draft-gont-6man-predictable- 921 fragment-id-00 (work in progress), December 2011. 923 [draft-gont-6man-stable-privacy-addresses-00] 924 Gont, F., "A method for Generating Stable Privacy-Enhanced 925 Addresses with IPv6 Stateless Address Autoconfiguration 926 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00 927 (work in progress), December 2011. 929 [draft-ietf-6man-default-iids-00] 930 Gont, F., Cooper, A., Thaler, D., and W. Liu, 931 "Recommendation on Stable IPv6 Interface Identifiers", 932 draft-ietf-6man-default-iids-00 (work in progress), July 933 2014. 935 [draft-ietf-6man-predictable-fragment-id-00] 936 Gont, F., "Security Implications of Predictable Fragment 937 Identification Values", draft-ietf-6man-predictable- 938 fragment-id-00 (work in progress), March 2013. 940 [draft-ietf-6man-predictable-fragment-id-01] 941 Gont, F., "Security Implications of Predictable Fragment 942 Identification Values", draft-ietf-6man-predictable- 943 fragment-id-01 (work in progress), April 2014. 945 [draft-ietf-6man-predictable-fragment-id-02] 946 Gont, F., "Security Implications of Predictable Fragment 947 Identification Values", draft-ietf-6man-predictable- 948 fragment-id-02 (work in progress), December 2014. 950 [draft-ietf-6man-predictable-fragment-id-08] 951 Gont, F., "Security Implications of Predictable Fragment 952 Identification Values", draft-ietf-6man-predictable- 953 fragment-id-08 (work in progress), June 2015. 955 [draft-ietf-6man-rfc4941bis-00] 956 Gont, F., Krishnan, S., Narten, T., and R. Draves, 957 "Privacy Extensions for Stateless Address 958 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00 959 (work in progress), July 2018. 961 [draft-ietf-6man-stable-privacy-addresses-00] 962 Gont, F., "A method for Generating Stable Privacy-Enhanced 963 Addresses with IPv6 Stateless Address Autoconfiguration 964 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 965 (work in progress), May 2012. 967 [draft-ietf-ntp-refid-updates-00] 968 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 969 REFID", draft-ietf-ntp-refid-updates-00 (work in 970 progress), November 2016. 972 [draft-stenn-ntp-not-you-refid-00] 973 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 974 REFID", draft-stenn-ntp-not-you-refid-00 (work in 975 progress), July 2016. 977 [Fyodor2002] 978 Fyodor, "Idle scanning and related IP ID games", 2002, 979 . 981 [Gont-NTP] 982 Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- 983 05", Post to the NTP WG mailing list Message-ID: 984 , 985 April 2019, . 988 [Gont2011] 989 Gont, F., "Hacking IPv6 Networks (training course)", Hack 990 In Paris 2011 Conference Paris, France, June 2011. 992 [Gont2012] 993 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 994 Conference Ottawa, Canada. May 11-12, 2012, May 2012, 995 . 999 [Gont2013] 1000 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit 1001 (help wanted!)", Message posted to the IPv6 Hackers 1002 mailing-list Message-ID: 1003 <51184548.3030105@si6networks.com>, 2013, 1004 . 1007 [I-D.cooper-6man-ipv6-address-generation-privacy] 1008 Cooper, A., Gont, F., and D. Thaler, "Privacy 1009 Considerations for IPv6 Address Generation Mechanisms", 1010 draft-cooper-6man-ipv6-address-generation-privacy-00 (work 1011 in progress), July 2013. 1013 [I-D.eddy-rfc793bis-04] 1014 Eddy, W., "Transmission Control Protocol Specification", 1015 draft-eddy-rfc793bis-04 (work in progress), August 2014. 1017 [I-D.gont-6man-predictable-fragment-id] 1018 Gont, F., "Security Implications of Predictable Fragment 1019 Identification Values", draft-gont-6man-predictable- 1020 fragment-id-03 (work in progress), January 2013. 1022 [I-D.gont-6man-stable-privacy-addresses] 1023 Gont, F., "A method for Generating Stable Privacy-Enhanced 1024 Addresses with IPv6 Stateless Address Autoconfiguration 1025 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01 1026 (work in progress), March 2012. 1028 [I-D.gont-ntp-port-randomization] 1029 Gont, F. and G. Gont, "Port Randomization in the Network 1030 Time Protocol Version 4", draft-gont-ntp-port- 1031 randomization-04 (work in progress), August 2019. 1033 [I-D.gont-numeric-ids-sec-considerations] 1034 Gont, F. and I. Arce, "Security Considerations for 1035 Transient Numeric Identifiers Employed in Network 1036 Protocols", draft-gont-numeric-ids-sec-considerations-06 1037 (work in progress), December 2020. 1039 [I-D.gont-opsec-ipv6-host-scanning] 1040 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1041 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in 1042 progress), October 2012. 1044 [I-D.gont-predictable-numeric-ids] 1045 Gont, F. and I. Arce, "Security and Privacy Implications 1046 of Numeric Identifiers Employed in Network Protocols", 1047 draft-gont-predictable-numeric-ids-03 (work in progress), 1048 March 2019. 1050 [I-D.ietf-6man-default-iids] 1051 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1052 "Recommendation on Stable IPv6 Interface Identifiers", 1053 draft-ietf-6man-default-iids-16 (work in progress), 1054 September 2016. 1056 [I-D.ietf-6man-ipv6-address-generation-privacy] 1057 Cooper, A., Gont, F., and D. Thaler, "Privacy 1058 Considerations for IPv6 Address Generation Mechanisms", 1059 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 1060 in progress), September 2015. 1062 [I-D.ietf-6man-predictable-fragment-id] 1063 Gont, F., "Security Implications of Predictable Fragment 1064 Identification Values", draft-ietf-6man-predictable- 1065 fragment-id-10 (work in progress), October 2015. 1067 [I-D.ietf-6man-rfc2460bis] 1068 Deering, S. and R. Hinden, "Internet Protocol, Version 6 1069 (IPv6) Specification", draft-ietf-6man-rfc2460bis-12 (work 1070 in progress), May 2017. 1072 [I-D.ietf-6man-rfc4941bis] 1073 Gont, F., Krishnan, S., Narten, T., and R. Draves, 1074 "Temporary Address Extensions for Stateless Address 1075 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12 1076 (work in progress), November 2020. 1078 [I-D.ietf-6man-stable-privacy-addresses] 1079 Gont, F., "A Method for Generating Semantically Opaque 1080 Interface Identifiers with IPv6 Stateless Address 1081 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 1082 privacy-addresses-17 (work in progress), January 2014. 1084 [I-D.ietf-ntp-port-randomization] 1085 Gont, F., Gont, G., and M. Lichvar, "Port Randomization in 1086 the Network Time Protocol Version 4", draft-ietf-ntp-port- 1087 randomization-06 (work in progress), September 2020. 1089 [I-D.ietf-ntp-refid-updates] 1090 Stenn, H. and S. Goldberg, "Network Time Protocol REFID 1091 Updates", draft-ietf-ntp-refid-updates-05 (work in 1092 progress), March 2019. 1094 [I-D.ietf-opsec-ipv6-host-scanning] 1095 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1096 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 1097 progress), August 2015. 1099 [I-D.irtf-pearg-numeric-ids-generation] 1100 Gont, F. and I. Arce, "On the Generation of Transient 1101 Numeric Identifiers", draft-irtf-pearg-numeric-ids- 1102 generation-06 (work in progress), January 2021. 1104 [IANA-PROT] 1105 IANA, "Protocol Registries", 1106 . 1108 [IPID-DEV] 1109 Klein, A. and B. Pinkas, "From IP ID to Device ID and 1110 KASLR Bypass (Extended Version)", June 2019, 1111 . 1113 [IPv6-Toolkit] 1114 SI6 Networks, "SI6 Networks' IPv6 Toolkit", 1115 . 1117 [Klein2007] 1118 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 1119 Predictable IP ID Vulnerability", 2007, 1120 . 1124 [Morbitzer2013] 1125 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message 1126 posted to the nmap-dev mailing-list, 2013, 1127 . 1129 [Morris1985] 1130 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1131 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1132 NJ, 1985, 1133 . 1135 [NIST-NTP] 1136 Sherman, J. and J. Levine, "Usage Analysis of the NIST 1137 Internet Time Service", Journal of Research of the 1138 National Institute of Standards and Technology Volume 121, 1139 March 2016, . 1141 [NTP-PORTR] 1142 Gont, F., "[Ntp] New rev of the NTP port randomization I-D 1143 (Fwd: New Version Notification for draft-gont-ntp-port- 1144 randomization-01.txt)", 2019, 1145 . 1148 [OpenBSD-IPv4-ID] 1149 OpenBSD, "Randomization of the IPv4 Identification field", 1150 December 1998, 1151 . 1154 [OpenBSD-IPv6-ID] 1155 OpenBSD, "Randomization of the IPv6 Identification field", 1156 October 2003, 1157 . 1160 [OpenBSD-PR] 1161 OpenBSD, "Implementation of port randomization", July 1162 1996, . 1165 [OpenBSD-TCP-ISN-H] 1166 OpenBSD, "Implementation of RFC1948 for TCP ISN 1167 randomization", December 2000, 1168 . 1171 [OpenBSD-TCP-ISN-I] 1172 OpenBSD, "Implementation of TCP ISN randomization based on 1173 random increments", July 1996, 1174 . 1177 [OpenBSD-TCP-ISN-R] 1178 OpenBSD, "Implementation of TCP ISN randomization based on 1179 simple randomization", December 2000, 1180 . 1183 [RedHat2011] 1184 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 1185 Important: kernel security and bug fix update", 2011, 1186 . 1188 [RFC1035] Mockapetris, P., "Domain names - implementation and 1189 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1190 November 1987, . 1192 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1193 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1194 . 1196 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1197 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1198 . 1200 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1201 "Network Time Protocol Version 4: Protocol and Algorithms 1202 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1203 . 1205 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1206 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 1207 . 1209 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1210 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1211 2014, . 1213 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1214 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1215 . 1217 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1218 Considerations for IPv6 Address Generation Mechanisms", 1219 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1220 . 1222 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1223 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1224 February 2016, . 1226 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1227 "Recommendation on Stable IPv6 Interface Identifiers", 1228 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1229 . 1231 [Sanfilippo1998a] 1232 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1233 mailing-list, Mon Dec 14 1998, 1234 . 1236 [Sanfilippo1998b] 1237 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1238 1998, . 1241 [Sanfilippo1999] 1242 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1243 list, 1999, 1244 . 1247 [Schuba1993] 1248 Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME 1249 SYSTEM PROTOCOL", 1993, 1250 . 1253 [Shimomura1995] 1254 Shimomura, T., "Technical details of the attack described 1255 by Markoff in NYT", Message posted in USENET's 1256 comp.security.misc newsgroup Message-ID: 1257 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1258 . 1260 [Silbersack2005] 1261 Silbersack, M., "Improving TCP/IP security through 1262 randomization without sacrificing interoperability", 1263 EuroBSDCon 2005 Conference, 2005, 1264 . 1267 [SUSE2011] 1268 SUSE, "SUSE Security Announcement: Linux kernel security 1269 update (SUSE-SA:2011:046)", 2011, 1270 . 1273 [Ubuntu2011] 1274 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 1275 vulnerabilities", 2011, 1276 . 1278 [USCERT2001] 1279 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 1280 TCP/IP implementations may use statistically predictable 1281 initial sequence numbers", 2001, 1282 . 1284 [VU-800113] 1285 CERT/CC, "Multiple DNS implementations vulnerable to cache 1286 poisoning (Vulnerability Note VU#800113)", July 2008, 1287 . 1289 [Wright1994] 1290 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1291 The Implementation", Addison-Wesley, 1994. 1293 [Zalewski2001] 1294 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1295 Number Analysis", 2001, 1296 . 1298 [Zalewski2002] 1299 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1300 Number Analysis - One Year Later", 2001, 1301 . 1303 [Zalewski2003] 1304 Zalewski, M., "A new TCP/IP blind data injection 1305 technique?", 2003, 1306 . 1308 Authors' Addresses 1310 Fernando Gont 1311 SI6 Networks 1312 Evaristo Carriego 2644 1313 Haedo, Provincia de Buenos Aires 1706 1314 Argentina 1316 Phone: +54 11 4650 8472 1317 Email: fgont@si6networks.com 1318 URI: https://www.si6networks.com 1320 Ivan Arce 1321 Quarkslab 1323 Email: iarce@quarkslab.com 1324 URI: https://www.quarkslab.com