Internet Research Task Force (IRTF)                              F. Gont
Internet-Draft
Request for Comments: 9414                                  SI6 Networks
Intended status:
Category: Informational                                          I. Arce
Expires: 14 June 2023
ISSN: 2070-1721                                                Quarkslab
                                                        11 December 2022
                                                               July 2023

          Unfortunate History of Transient Numeric Identifiers
                draft-irtf-pearg-numeric-ids-history-11

Abstract

   This document analyzes the timeline of the specification and
   implementation of different types of "transient numeric identifiers"
   used in IETF protocols, protocols and how the security and privacy properties of
   such protocols have been affected as a result of it.  It provides
   empirical evidence that advice in this area is warranted.  This
   document is a product of the Privacy Enhancement Enhancements and Assessment Assessments
   Research Group (PEARG) in the IRTF.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the
   provisions results of BCP 78 Internet-related research
   and BCP 79.

   Internet-Drafts are working documents development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Privacy
   Enhancements and Assessments Research Group of the Internet Engineering Research
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts (IRTF).  Documents approved for publication by the IRSG
   are draft documents valid not candidates for a maximum any level of Internet Standard; see Section 2
   of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 June 2023.
   https://www.rfc-editor.org/info/rfc9414.

Copyright Notice

   Copyright (c) 2022 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Issues with the Specification of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  IPv4/IPv6 Identification  . . . . . . . . . . . . . . . .   6
     4.2.  TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . .  10
     4.3.  IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . .  12
     4.4.  NTP Reference IDs (REFIDs)  . . . . . . . . . . . . . . .  15
     4.5.  Transport Protocol  Transport-Protocol Ephemeral Port Numbers . . . . . . . .  16
     4.6.  DNS Query ID  . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     9.1.
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     9.2.
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

1.  Introduction

   Networking protocols employ a variety of transient numeric
   identifiers for different protocol objects, such as IPv4 and IPv6
   Fragment Identifiers
   Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers
   (IIDs) [RFC4291], transport protocol transport-protocol ephemeral port numbers
   [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], [RFC9293], NTP
   Reference IDs (REFIDs) [RFC5905], and DNS Query IDs [RFC1035].  These
   identifiers typically have specific interoperability requirements
   (e.g. (e.g., uniqueness
   during a specified period of time), time) that must be satisfied such that
   they do not result in negative interoperability implications and an
   associated failure severities severity when such requirements are not met
   [I-D.irtf-pearg-numeric-ids-generation].
   [RFC9415].

      |  NOTE: Some documents refer to the DNS ID as the DNS "Query ID"
      |  or "TxID".

   For more than 30 years, a large number of implementations of the IETF
   protocols have been subject to a variety of attacks, with effects
   ranging from Denial of Service (DoS) or data injection, injection to information
   leakages that could be exploited for pervasive monitoring [RFC7258].
   The root cause of these issues has been, in many cases, the poor
   selection of transient numeric identifiers, identifiers in such protocols, usually
   as a result of insufficient or misleading specifications.  While it
   is generally trivial to identify an algorithm that can satisfy the
   interoperability requirements of a given transient numeric
   identifier, empirical evidence exists that doing so without
   negatively affecting the security and/or privacy properties of the
   aforementioned protocols is prone to error.

   For example, implementations have been subject to security or and/or
   privacy issues resulting from:

   *  Predictable  predictable IPv4 or IPv6 Fragment Identifiers (see e.g. Identification values (e.g., see
      [Sanfilippo1998a], [RFC6274], and [RFC7739]) [RFC7739]),

   *  Predictable  predictable IPv6 IIDs (see e.g.  [RFC7721], (e.g., see [RFC7217], [RFC7707], and
      [RFC7217])
      [RFC7721]),

   *  Predictable transport protocol  predictable transport-protocol ephemeral port numbers (see e.g. (e.g., see
      [RFC6056] and [Silbersack2005]) [Silbersack2005]),

   *  Predictable  predictable TCP Initial Sequence Numbers (ISNs) (see e.g. (e.g., see
      [Morris1985], [Bellovin1989], and [RFC6528]) [RFC6528]),

   *  Predictable  predictable initial timestamps in TCP timestamps options (e.g.,
      see [TCPT-uptime] and [RFC7323]), and

   *  predictable DNS Query IDs (see e.g.  [Arce1997] (see, e.g., [Schuba1993] and [Klein2007])

   These examples indicate that [Klein2007]).

   Recent history indicates that, when new protocols are standardized or
   implemented,
   new protocol implementations are produced, the security and privacy
   properties of the associated transient numeric identifiers tend to be
   overlooked, and inappropriate algorithms to generate such identifiers (i.e. that
   negatively affect the security or privacy properties of the protocol)
   are either suggested in the specification specifications or selected by
   implementers.  As a result, advice in this area is warranted.

   This document contains a non-exhaustive timeline of the specification
   and vulnerability disclosures related to some sample transient
   numeric identifiers, including other work that has led to advances in
   this area.  This analysis indicates that:

   *  Vulnerabilities  vulnerabilities associated with the inappropriate generation of
      transient numeric identifiers have affected protocol
      implementations for an extremely long period of time. time,

   *  Such  such vulnerabilities, even when addressed for a given protocol
      version, were later reintroduced in new versions or new
      implementations of the same protocol. protocol, and

   *  Standardization  standardization efforts that discuss and provide advice in this
      area can have a positive effect on IETF specifications and their
      corresponding implementations.

   While it is generally possible to identify an algorithm that can
   satisfy the interoperability requirements for a given transient
   numeric identifier, this document provides empirical evidence that
   doing so without negatively affecting the security or and/or privacy
   properties of the aforementioned corresponding protocols is non-trivial. nontrivial.  Other
   related documents ([I-D.irtf-pearg-numeric-ids-generation] ([RFC9415] and
   [I-D.gont-numeric-ids-sec-considerations]) [RFC9416]) provide guidance in this
   area, as motivated by the present document.

   This document represents the consensus of the Privacy Enhancement Enhancements
   and
   Assessment Assessments Research Group (PEARG).

2.  Terminology

   Transient Numeric Identifier:
      A data object in a protocol specification that can be used to
      definitely distinguish a protocol object (a datagram, network
      interface, transport protocol transport-protocol endpoint, session, etc) etc.) from all
      other objects of the same type, in a given context.  Transient
      numeric identifiers are usually defined as a series of bits, bits and
      represented using integer values.  These identifiers are typically
      dynamically selected, as opposed to statically-assigned statically assigned numeric
      identifiers (see e.g. (e.g., see [IANA-PROT]).  We note that different
      transient numeric identifiers may have additional requirements or
      properties depending on their specific use in a protocol.  We use
      the term "transient numeric identifier" (or simply "numeric
      identifier" or "identifier" as short forms) as a generic term to
      refer to any data object in a protocol specification that
      satisfies the identification property stated above.

   The terms "constant IID", "stable IID", and "temporary IID" are to be
   interpreted as defined in [RFC7721].

3.  Threat Model

   Throughout this document, we do not consider on-path attacks.  That
   is, we assume the attacker does not have physical or logical access
   to the system(s) being attacked, attacked and that the attacker can only
   observe traffic explicitly directed to the attacker.  Similarly, an
   attacker cannot observe traffic transferred between a the sender and
   the receiver(s) of a target protocol, protocol but may be able to interact with
   any of these entities, including by e.g. by, e.g., sending any traffic to
   them to sample transient numeric identifiers employed by the target
   systems
   hosts when communicating with the attacker.

   For example, when analyzing vulnerabilities associated with TCP
   Initial Sequence Numbers (ISNs), we consider the attacker is unable
   to capture network traffic corresponding to a TCP connection between
   two other hosts.  However, we consider the attacker is able to
   communicate with any of these hosts (e.g., establish a TCP connection
   with any of them), to e.g. them) to, e.g., sample the TCP ISNs employed by these
   systems
   hosts when communicating with the attacker.

   Similarly, when considering host-tracking attacks based on IPv6
   interface identifiers,
   Interface Identifiers, we consider an attacker may learn the IPv6
   address employed by a victim node if e.g. host if, e.g., the address becomes
   exposed as a result of the victim node host communicating with an attacker-
   operated
   attacker-operated server.  Subsequently, an attacker may perform
   host-tracking by probing a set of target addresses composed by a set
   of target prefixes and the IPv6 interface identifier Interface Identifier originally
   learned by the attacker.  Alternatively, an attacker may perform host tracking if
   e.g.
   host-tracking if, e.g., the victim node host communicates with an
   attacker-operated server as it moves from one location to another, those
   thereby exposing its configured addresses.  We note that none of
   these scenarios requires require the attacker observe traffic not explicitly
   directed to the attacker.

4.  Issues with the Specification of Transient Numeric Identifiers

   While assessing IETF protocol specifications regarding the use of
   transient numeric identifiers, we have found that most of the issues
   discussed in this document arise as a result of one of the following
   conditions:

   *  Protocol  protocol specifications that under-specify the requirements for under specify their transient numeric
      identifiers

   *  Protocol  protocol specifications that over-specify over specify their transient numeric
      identifiers

   *  Protocol  protocol implementations that simply fail to comply with the
      specified requirements

   A number of IETF protocol specifications have simply overlooked the
   security and privacy implications of under specified their
   transient numeric identifiers. identifiers, thus leading to implementations that
   were vulnerable to numerous off-path attacks.  Examples of them are
   the specification of TCP ephemeral local ports in
   [RFC0793], the specification of TCP sequence numbers in [RFC0793], [RFC0793] or the
   specification of the DNS TxID ID in [RFC1035].

      |  NOTE: The TCP local port in an active OPEN request is commonly
      |  known as the "ephemeral port" of the corresponding TCP
      |  connection [RFC6056].

   On the other hand, there are a number of IETF protocol specifications
   that over-specify over specify some of their associated transient numeric
   identifiers.  For example, [RFC4291] essentially overloads the
   semantics of IPv6 Interface Identifiers (IIDs) by embedding link-
   layer addresses in the IPv6 IIDs, IIDs when the interoperability
   requirement of uniqueness could be achieved in other ways that do not
   result in negative security and privacy implications [RFC7721].
   Similarly, [RFC2460] suggested suggests the use of a global counter for the
   generation of Fragment Identification values, values when the interoperability properties
   requirement of uniqueness per {Src IP, Dst IP} {IPv6 Source Address, IPv6 Destination
   Address} could be achieved with other algorithms that do not result
   in negative security and privacy implications [RFC7739].

   Finally, there are protocol implementations that simply fail to
   comply with
   the corresponding IETF existing protocol specifications or recommendations. specifications.  For example, some
   popular operating systems (notably Microsoft
   Windows) still fail to implement transport protocol transport-protocol
   ephemeral port randomization, as recommended in [RFC6056]. [RFC6056], or TCP
   Initial Sequence Number randomization, as recommended in [RFC9293].

   The following subsections document the timelines for a number of
   sample transient numeric identifiers, identifiers that illustrate how the problem
   discussed in this document has affected protocols from different
   layers over time.  These sample transient numeric identifiers have
   different interoperability requirements and failure severities (see
   Section 6 of [I-D.irtf-pearg-numeric-ids-generation]), [RFC9415]), and thus are considered to be representative
   of the problem being analyzed in this document.

4.1.  IPv4/IPv6 Identification

   This section presents the timeline of the Identification field
   employed by IPv4 (in the base header) and IPv6 (in Fragment Headers).
   The reason for presenting both cases in the same section is to make
   it evident that that, while the Identification value serves the same
   purpose in both IPv4 and IPv6, protocols, the work and research done for the IPv4
   case did not affect influence IPv6 specifications or implementations.

   The IPv4 Identification is specified in [RFC0791], which specifies
   the interoperability requirements for the Identification field: field, i.e.,
   the sender must choose the Identification field to be unique for a
   given
   source address, destination address, and protocol, {Source Address, Destination Address, Protocol} for the time
   the datagram (or any fragment of it) could be alive in the internet. Internet.
   It suggests that a node sending protocol module may keep "a table of
   Identifiers, one entry for each destination it has communicated with
   in the last maximum packet lifetime for the internet", [I]nternet", and it also
   suggests that "since the Identifier field allows 65,536 different
   values, hosts may be able to simply use unique identifiers
   independent of destination".  The above has been interpreted numerous
   times as a suggestion to employ per-destination or global counters
   for the generation of Identification values.  While [RFC0791] does
   not suggest any flawed algorithm for the generation of Identification
   values, the specification omits a discussion of the security and
   privacy implications of predictable Identification values.  This has
   resulted in many IPv4 implementations generating predictable fragment
   Identification values by means of a global counter, at least at some
   point in time.

   The IPv6 Identification was originally specified in [RFC1883].  It
   serves the same purpose as its IPv4 counterpart, with the only
   difference residing in the length of the corresponding field, and
   that while the IPv4 Identification field is but rather than
   being part of the base IPv4
   header, header (as in the IPv6 case IPv4 case), it is part of
   the Fragment header Header (which may or may not be present in an IPv6
   packet).  [RFC1883] states, in  Section 4.5, 4.5 of [RFC1883] states that the Identification
   must be different than that of any other fragmented packet sent
   recently (within the maximum likely lifetime of a packet) with the
   same Source Address and Destination Address.  Subsequently, it notes
   that this requirement can be met by means of a wrap-around 32-bit
   counter that is incremented each time a packet must be fragmented, fragmented and
   that it is an implementation choice whether to use a global or a per-destination per-
   destination counter.  Thus, the
   implementation specification of the IPv6
   Identification is similar to that of the IPv4 case, with the only
   difference that that, in the IPv6 case case, the suggestions to use simple
   counters is more explicit.  [RFC2460] was is the first revision of the
   core IPv6 specification, specification and maintained maintains the same text for the
   specification of the IPv6 Identification field.  [RFC8200], the
   second revision of the core IPv6 specification, removes the
   suggestion from [RFC2460] to use a counter for the generation of IPv6
   Identification values, values and points to [RFC7739] for sample algorithms
   for their generation.

   September 1981:
      [RFC0791] specifies the interoperability requirements for the IPv4
      Identification value, but does not perform a vulnerability assessment of
      this transient numeric identifier.

   December 1995:
      [RFC1883], the first specification of the IPv6 protocol, is
      published.  It suggests that a counter be used to generate the
      IPv6 Identification value, values and notes that it is an implementation
      choice whether to maintain a single counter for the node or
      multiple counters, e.g., counters (e.g., one for each of the node's possible
      source addresses,
      Source Addresses, or one for each active (source address,
      destination address) combination. {Source Address,
      Destination Address} set).

   December 1998:
      [Sanfilippo1998a] finds that predictable IPv4 Identification
      values (generated (as generated by most popular implementations) can be
      leveraged to count the number of packets sent by a target node.
      [Sanfilippo1998b] explains how to leverage the same vulnerability
      to implement a port-scanning technique known as "dumb/idle "idle scan".  A
      tool that implements this attack is publicly released.

   December 1998:
      [RFC2460], a revision of the IPv6 specification, is published,
      obsoleting [RFC1883].  It maintains the same specification of the
      IPv6 Identification field as its predecessor ([RFC1883]). [RFC1883].

   December 1998:
      OpenBSD implements randomization of the IPv4 Identification field
      [OpenBSD-IPv4-ID].

   November 1999:
      [Sanfilippo1999] discusses how to leverage predictable IPv4
      Identification values to uncover the rules of a number of
      firewalls.

   September 2002:
      [Fyodor2002] documents the implementation of the "idle/dumb "idle scan"
      technique in the popular nmap Network Mapper (nmap) tool.

   November 2002:
      [Bellovin2002] explains how the IPv4 Identification field can be
      exploited to count the number of systems behind a NAT.

   October 2003:
      OpenBSD implements randomization of the IPv6 Identification field
      [OpenBSD-IPv6-ID].

   December 2003:
      [Zalewski2003] explains a technique to perform TCP data injection
      attacks based on predictable IPv4 identification Identification values, which
      requires less effort than TCP injection attacks performed with
      bare TCP packets.

   November

   January 2005:
      [Silbersack2005] discusses shortcomings in a number of techniques
      to mitigate predictable IPv4 Identification values.

   October 2007:
      [Klein2007] describes a weakness in the pseudo random pseudorandom number
      generator (PRNG) in use for the generation of the IP Identification
      values by a number of operating systems.

   June 2011:
      [Gont2011] describes how to perform dumb/idle idle scan attacks in IPv6.

   November 2011:
      Linux mitigates predictable IPv6 Identification values
      [RedHat2011] [SUSE2011] [Ubuntu2011].

   December 2011:
      [draft-gont-6man-predictable-fragment-id-00] describes the
      security implications of predictable IPv6 Identification values, values
      and possible mitigations.  This document has the Intended Status intended status
      of "Standards Track", with the intention to formally update
      [RFC2460],
      [RFC2460] to introduce security and privacy requirements on the
      generation of IPv6 Identification values.

   May 2012:
      [Gont2012] notes that some major IPv6 implementations still employ
      predictable IPv6 Identification values.

   March 2013:
      The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], [draft-gont-6man-predictable-fragment-id-03]
      but changes the track to "BCP" (while still formally updating
      [RFC2460]), publishing posting the resulting document as
      [draft-ietf-6man-predictable-fragment-id-00].

   June 2013:
      A patch to incorporate support for IPv6-based idle/dumb idle scans in nmap
      is submitted [Morbitzer2013].

   December 2014:
      The 6man WG changes the Intended Status intended status of
      [draft-ietf-6man-predictable-fragment-id-01] to "Informational"
      and publishes posts it as [draft-ietf-6man-predictable-fragment-id-02].  As
      a result, it no longer formally updates [RFC2460], and security
      and privacy requirements on the generation of IPv6 Identification
      values are eliminated.

   June 2015:
      [draft-ietf-6man-predictable-fragment-id-08] notes that some
      popular host and router implementations still employ predictable
      IPv6 Identification values.

   February 2016:
      [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) [draft-ietf-6man-predictable-fragment-id-10])
      analyzes the security and privacy implications of predictable IPv6
      Identification values, values and provides guidance for selecting an
      algorithm to generate such values.  However, being published with
      the Intended Status of "Informational", as an
      "Informational" RFC, it does not formally update [RFC2460], [RFC2460] and
      does not introduce security and privacy requirements on the
      generation of IPv6 Identification values.

   June 2016:
      [I-D.ietf-6man-rfc2460bis],
      [draft-ietf-6man-rfc2460bis-05], a draft revision of [RFC2460],
      removes the suggestion from RFC2460 [RFC2460] to use a counter for the
      generation of IPv6 Identification values, values but does not perform a
      vulnerability assessment of the generation of IPv6 Identification values,
      values and does not introduce security and privacy requirements on
      the generation of IPv6 Identification values.

   July 2017:
      [I-D.ietf-6man-rfc2460bis]
      [draft-ietf-6man-rfc2460bis-13] is finally published as [RFC8200],
      obsoleting [RFC2460], [RFC2460] and pointing to [RFC7739] for sample
      algorithms for the generation of IPv6 Fragment Identification values.
      However, it does not introduce security and privacy requirements
      on the generation of IPv6 Identification values.

   June

   October 2019:
      [IPID-DEV] notes that the IPv6 ID Identification generators of two
      popular operating systems are flawed.

4.2.  TCP Initial Sequence Numbers (ISNs)

   [RFC0793] suggests that the choice of the ISN of a connection is not
   arbitrary,
   arbitrary but aims to reduce the chances of a stale segment from
   being accepted by a new incarnation of a previous connection.
   [RFC0793] suggests the use of a global 32-bit ISN generator that is
   incremented by 1 roughly every 4 microseconds.  However, as a matter
   of fact, protection against stale segments from a previous
   incarnation of the connection is enforced by preventing the creation
   of a new incarnation of a previous connection before 2*MSL have has passed
   since a segment corresponding to the old incarnation was last seen
   (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]).  This is
   accomplished by the TIME-WAIT state and TCP's "quiet time" concept
   (see Appendix B of [RFC1323]).  Based on the assumption that ISNs are
   monotonically increasing across connections, many stacks (e.g.,
   4.2BSD-derived) use the ISN of an incoming SYN segment to perform
   "heuristics" that enable the creation of a new incarnation of a
   connection while the previous incarnation is still in the TIME-WAIT
   state (see p. 945 of [Wright1994]).  This avoids an interoperability
   problem that may arise when a node establishes connections to a
   specific TCP end-point at a high rate [Silbersack2005].

   The interoperability requirements for TCP ISNs are probably not as
   clearly spelled out as one would expect.  Furthermore, the suggestion
   of employing a global counter in [RFC0793] negatively affects the
   security and privacy properties of the protocol.

   September 1981:
      [RFC0793],
      [RFC0793] suggests the use of a global 32-bit ISN generator, whose
      lower bit is incremented roughly every 4 microseconds.  However,
      such an ISN generator makes it trivial to predict the ISN that a
      TCP instance implementation will use for new connections, thus allowing a
      variety of attacks against TCP.

   February 1985:
      [Morris1985] was is the first to describe how to exploit predictable
      TCP ISNs for forging TCP connections that could then be leveraged
      for trust relationship exploitation.

   April 1989:
      [Bellovin1989] discussed discusses the security considerations for
      predictable ISNs (along with a range of other protocol-based
      vulnerabilities).

   February

   January 1995:
      [Shimomura1995] reported reports a real-world exploitation of the attack
      vulnerability described in [Morris1985] ten years before (in
      1985).

   May 1996:
      [RFC1948] was is the first IETF effort, authored by Steven Bellovin,
      to address predictable TCP ISNs.  However, [RFC1948] does not
      formally update [RFC0793].  Note: The same concept specified in
      this document for TCP ISNs was later proposed for TCP ephemeral
      ports [RFC6056], TCP Timestamps, and eventually even IPv6
      Interface Identifiers [RFC7217].

   July 1996:
      OpenBSD implements TCP ISN randomization based on random
      increments (please see Appendix A.2 of
      [I-D.irtf-pearg-numeric-ids-generation]) [RFC9415])
      [OpenBSD-TCP-ISN-I].

   December 2000:
      OpenBSD implements TCP ISN randomization using simple
      randomization (please see Section 7.1 of
      [I-D.irtf-pearg-numeric-ids-generation]) [RFC9415])
      [OpenBSD-TCP-ISN-R].

   March 2001:
      [Zalewski2001] provides a detailed analysis of statistical
      weaknesses in some TCP ISN generators, generators and includes a survey of the
      algorithms in use by popular TCP implementations.

   May 2001:  Vulnerability
      advisories [CERT2001] [USCERT2001] were released regarding statistical
      weaknesses in some TCP ISN generators, affecting popular TCP
      implementations.  Other vulnerability advisories on the same
      vulnerability, such as [CERT2001], were published later on.

   March 2002:
      [Zalewski2002] updates and complements [Zalewski2001].  It
      concludes that "while some vendors [...] reacted promptly and
      tested their solutions properly, many still either ignored the
      issue and never evaluated their implementations, or implemented a
      flawed solution that apparently was not tested using a known
      approach" [Zalewski2002].

   June 2007:
      OpenBSD implements TCP ISN randomization based on the algorithm
      specified in [RFC1948] (currently obsoleted and replaced by
      [RFC6528]) for the TCP endpoint that performs the active open, open
      while keeping the simple randomization scheme for the endpoint
      performing the passive open [OpenBSD-TCP-ISN-H].  This provides
      monotonically-increasing
      monotonically increasing ISNs for the client side "client side" (allowing the
      BSD heuristics to work as expected), expected) while avoiding any patterns in
      the ISN generation for the server side. "server side".

   February 2012:
      [RFC6528], published 27 years after Morris' Morris's original work
      [Morris1985], formally updates [RFC0793] to mitigate predictable
      TCP ISNs.

   August 2014:
      [I-D.eddy-rfc793bis-04],
      The algorithm specified in [RFC6528] becomes the upcoming recommended
      ("SHOULD") algorithm for TCP ISN generation in
      [draft-eddy-rfc793bis-04], an early revision of the core TCP
      specification [RFC9293].

   August 2022:
      [RFC9293], a revision of the core TCP
      protocol specification, incorporates is published,
      adopting the algorithm specified in [RFC6528] as the recommended
      ("SHOULD") algorithm for TCP ISN generation.

4.3.  IPv6 Interface Identifiers (IIDs)

   IPv6 Interface Identifiers can be generated as a result of different
   mechanisms, including SLAAC Stateless Address Autoconfiguration (SLAAC)
   [RFC4862], DHCPv6 [RFC8415], and manual configuration.  This section
   focuses on Interface Identifiers resulting from SLAAC.

   The Interface Identifier of stable (traditional) IPv6 addresses resulting from
   SLAAC have traditionally originally resulted in the underlying link-layer address being
   embedded in the IID.At IID.  At the time, employing the underlying link-layer link-
   layer address for the IID was seen as a convenient way to obtain a
   unique address.  However, recent awareness about the security and
   privacy properties of this approach [RFC7707] [RFC7721] has led to
   the replacement of this flawed scheme with an alternative one
   [RFC7217] [RFC8064] that does not negatively affect the security and
   privacy properties of the protocol.

   January 1997:
      [RFC2073] specifies the syntax of IPv6 global addresses (referred
      to as "An IPv6 Provider-Based Unicast Address Format" at the
      time), which is consistent with the IPv6 addressing architecture
      specified in [RFC1884].  Hosts are recommended to "generate
      addresses using link-specific addresses as Interface ID such as 48
      bit IEEE-802 MAC addresses".

   July 1998:
      [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address
      Format" (obsoleting [RFC2373]) [RFC2073]), changing the size of the IID to 64
      bits, and specifies that IIDs must be constructed in IEEE EUI-64 64-bit
      Extended Unique Identifier (EUI-64) format.  How such identifiers
      are constructed becomes is specified in the corresponding "IPv6 over
      <link>" specifications, such as "IPv6 over Ethernet".

   January 2001:
      [RFC3041] recognizes the problem of IPv6 network activity correlation,
      correlation and specifies IPv6 temporary addresses.  Temporary
      addresses are to be used along with stable addresses.

   August 2003:
      [RFC3587] obsoletes [RFC2374], making the TLA/NLA Top-Level Aggregator
      (TLA) / Next-Level Aggregator (NLA) structure
      historic.  The historic, though the
      syntax and recommendations for the traditional stable IIDs remain unchanged, though. unchanged.

   February 2006:
      [RFC4291] is published as the latest "IP Version 6 Addressing
      Architecture", requiring the IIDs of "all unicast addresses,
      except those that start with the traditional (stable) IPv6
      addresses resulting from SLAAC binary value 000" to employ the
      Modified EUI-64 format.  The details of constructing such
      interface identifiers are defined in the corresponding "IPv6 over
      <link>" specifications.

   March 2008:
      [RFC5157] provides hints regarding how patterns in IPv6 addresses
      could be leveraged for the purpose of address scanning.

   December 2011:
      [draft-gont-6man-stable-privacy-addresses-00] notes that the
      traditional
      original scheme for generating stable addresses allows for IPv6
      address scanning, scanning and also does not prevent for active node tracking. host tracking (even when IPv6
      temporary addresses are employed).  It also specifies an
      alternative algorithm meant to replace IIDs based on Modified
      EUI-64 format identifiers.

   November 2012:
      The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] [draft-gont-6man-stable-privacy-addresses-01]
      as a working group item (as
      [draft-ietf-6man-stable-privacy-addresses-00]).  However, the
      document no longer formally updates [RFC4291], and therefore [RFC4291]; therefore, the
      specified algorithm no longer formally replaces the Modified
      EUI-64 format identifiers.

   February 2013:
      An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages
      IPv6 address patterns is released [Gont2013].

   July 2013:
      [I-D.cooper-6man-ipv6-address-generation-privacy]
      [draft-cooper-6man-ipv6-address-generation-privacy-00] elaborates
      on the security and privacy properties of all known algorithms for
      generating IPv6 IIDs.

   January 2014:
      The 6man WG publishes posts [draft-ietf-6man-default-iids-00]
      ("Recommendation on Stable IPv6 Interface Identifiers"),
      recommending [I-D.ietf-6man-stable-privacy-addresses] [draft-ietf-6man-stable-privacy-addresses-17] for the
      generation of stable addresses.

   April 2014:
      [RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) [draft-ietf-6man-stable-privacy-addresses-17])
      is published, specifying "A Method for Generating Semantically
      Opaque Interface Identifiers with IPv6 Stateless Address
      Autoconfiguration (SLAAC)" as an alternative to (but *not*
      replacement of) Modified EUI-64 format IIDs.

   March 2016:
      [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], [draft-gont-opsec-ipv6-host-scanning-02] and
      later
      [I-D.ietf-opsec-ipv6-host-scanning]), [draft-ietf-opsec-ipv6-host-scanning-08]), about "Network
      Reconnaissance in IPv6 Networks", is published.

   March 2016:
      [RFC7721] (formerly
      [I-D.cooper-6man-ipv6-address-generation-privacy]
      [draft-cooper-6man-ipv6-address-generation-privacy-00] and later
      [I-D.ietf-6man-ipv6-address-generation-privacy]),
      [draft-ietf-6man-ipv6-address-generation-privacy-08]), about
      "Security and Privacy Considerations for IPv6 Address Generation
      Mechanisms", is published.

   May 2016:
      [draft-gont-6man-non-stable-iids-00] is published, posted, with the goal of
      specifying requirements for non-stable addresses, addresses and updating
      [RFC4941] such that use of only temporary addresses is allowed.

   May 2016:
      [draft-gont-6man-address-usage-recommendations-00] is published, posted,
      providing an analysis of how different aspects on an address (from
      stability to usage mode) affect their corresponding security and
      privacy properties, properties and meaning to eventually provide advice in
      this area.

   February 2017:
      The
      [draft-ietf-6man-default-iids-16], produced by the 6man WG publishes WG, is
      published as [RFC8064] ("Recommendation on Stable IPv6 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]),
      Identifiers"), with requirements for stable addresses and a
      recommendation to employ [RFC7217] for the generation of stable
      addresses.  It formally updates a large number of RFCs.

   March 2018:
      [draft-fgont-6man-rfc4941bis-00] is published posted (as suggested by the
      6man WG), WG) to address flaws in [RFC4941] by revising it (as an
      alternative to the [draft-gont-6man-non-stable-iids-00] effort,
      published
      posted in March 2016).

   July 2018:
      [draft-fgont-6man-rfc4941bis-00] is adopted (as
      [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG.

   December 2020:
      [I-D.ietf-6man-rfc4941bis]
      [draft-ietf-6man-rfc4941bis-12] is approved by the IESG for
      publication as an RFC.

   February 2021:
      [I-D.ietf-6man-rfc4941bis]
      [draft-ietf-6man-rfc4941bis-12] is finally published as [RFC8981].

4.4.  NTP Reference IDs (REFIDs)

   The NTP [RFC5905] Reference ID is a 32-bit code identifying the
   particular server or reference clock.  Above stratum 1 (secondary
   servers and clients), this value can be employed to avoid degree-one
   timing loops; loops, that is, scenarios where two NTP peers are (mutually)
   the time source of each other.  If using the IPv4 address family, the
   identifier is the four-octet IPv4 address.  If using the IPv6 address
   family, it is the first four octets of the MD5 hash of the IPv6
   address.

   June 2010:
      [RFC5905], "Network
      [RFC5905] ("Network Time Protocol Version 4: Protocol and
      Algorithms Specification" Specification") is published.  It specifies that that, for
      NTP peers with stratum higher than 1 1, the REFID embeds the IPv4 Address
      address of the time source or an the first four octets of the MD5
      hash of the IPv6 address of the time source.

   July 2016:
      [draft-stenn-ntp-not-you-refid-00] is published, posted, describing the
      information leakage produced via the NTP REFID.  It proposes that
      NTP returns a special REFID when a packet employs an IP Source
      Address that is not believed to be a current NTP peer, peer but
      otherwise generates and returns the traditional common REFID.  It is
      subsequently adopted by the NTP WG as
      [I-D.ietf-ntp-refid-updates].
      [draft-ietf-ntp-refid-updates-00].

   April 2019:
      [Gont-NTP] notes that the proposed fix specified in
      [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-
      optimal.  As a result of a lack of WG support, the
      [draft-ietf-ntp-refid-updates-00] effort is eventually abandoned.

4.5.  Transport Protocol  Transport-Protocol Ephemeral Port Numbers

   Most (if not all) transport protocols employ "port numbers" to
   demultiplex packets to the corresponding transport protocol transport-protocol
   instances.  "Ephemeral ports" refer to the local ports employed in
   active OPEN requests, that is, typically the local port numbers
   employed on the side initiating the communication.

   August 1980:
      [RFC0768] notes that the UDP source port is optional and
      identifies the port of the sending process.  It does not specify
      interoperability requirements for source port selection, nor does
      it suggest possible ways to select port numbers.  Most popular
      implementations end up selecting source ports from a system-wide
      global counter.

   September 1981:
      [RFC0793] (the TCP specification) essentially describes the use of
      port numbers, numbers and specifies that port numbers should result in a
      unique socket pair (local {local address, local port, remote address,
      remote port). port}. How ephemeral ports (i.e. port numbers for "active
      opens") are selected, selected and the port range
      from which they are
      selected, selected are left unspecified.

   July 1996:
      OpenBSD implements ephemeral port randomization [OpenBSD-PR].

   July 2008:
      The CERT Coordination Centre published Center publishes details of what became
      known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the
      DNS.  The attack exploited exploits the lack of source ephemeral port randomization
      and DNS ID randomization in many major DNS implementations to
      perform cache poisoning in an effective and practical manner.

   January 2009:
      [RFC5452] mandates the use of port randomization for DNS
      resolvers, resolvers
      and mandates that implementations must randomize ports from the
      range of available ports (53 or 1024, 1024 and above) or the largest that is as large
      as possible
      port range. and practicable.  It does not recommend possible
      algorithms for port randomization, although the document
      specifically targets DNS resolvers, for which a simple port
      randomization suffices (e.g. (e.g., Algorithm 1 of [RFC6056]).  This
      document led to the implementation of port randomization in the
      DNS resolver resolvers themselves, rather than in the underlying transport-protocols. transport
      protocols.

   January 2011:
      [RFC6056] notes that many TCP and UDP implementations result in
      predictable ephemeral port numbers, numbers and also notes that many
      implementations select port numbers from a small portion of the
      whole port number space.  It recommends the implementation and use
      of ephemeral port randomization, proposes a number of possible
      algorithms for port randomization, and also recommends to
      randomize port numbers over the range 1024-65535.

   March 2016:
      [NIST-NTP] reports a non-normal distribution of the ephemeral port
      numbers employed by the NTP clients of an Internet Time Service.

   April 2019:
      [I-D.gont-ntp-port-randomization]
      [draft-gont-ntp-port-randomization-00] notes that some NTP
      implementations employ the NTP service port (123) as the local
      port for non-symmetric modes, nonsymmetric modes and aims to update the NTP
      specification to recommend port randomization in such cases, which
      is in line with [RFC6056].  The proposal experiences some push-back pushback
      in the relevant working group (NTP WG) [NTP-PORTR], [NTP-PORTR] but is finally
      adopted as a working group item as
      [I-D.ietf-ntp-port-randomization].
      [draft-ietf-ntp-port-randomization-00].

   August 2021:
      [I-D.ietf-ntp-port-randomization]
      [draft-ietf-ntp-port-randomization-08] is finally published as
      [RFC9109].

4.6.  DNS Query ID

   The DNS Query ID [RFC1035] can be employed to match DNS replies to
   outstanding DNS queries.

      |  NOTE: Some documents refer to the DNS ID as the DNS "Query ID"
      |  or "TxID".

   November 1987:
      [RFC1035] specifies that the DNS ID is a 16 bit 16-bit identifier
      assigned by the program that generates any kind of query, query and that
      this identifier is copied in the corresponding reply and can be
      used by the requester to match up replies to outstanding queries.
      It does not specify the interoperability requirements for these this
      numeric
      identifiers, identifier, nor does it suggest an algorithm for
      generating them. it.

   August 1993:
      [Schuba1993] describes DNS cache poisoning attacks that require
      the attacker to guess the Query DNS ID.

   June 1995:
      [Vixie1995] suggests that both the UDP source port and the DNS ID
      of query packets should be randomized, although that might not
      provide enough entropy to prevent an attacker from guessing these
      values.

   April 1997:
      [Arce1997] finds that implementations employ predictable UDP
      source ports and predictable Query IDs, DNS IDs and argues that both should
      be randomized.

   November 2002:
      [Sacramento2002] finds that that, by spoofing multiple requests for the
      same domain name from different IP addresses, an attacker may
      guess the Query DNS ID employed for a victim with a high probability of
      success, thus performing allowing for DNS cache poisoning attacks.

   March 2007:
      [Klein2007c] finds that the Microsoft Windows DNS server generates
      predictable DNS ID values.

   July 2007:
      [Klein2007b] finds that a popular DNS server software (BIND 9)
      that randomizes the Query DNS ID is still subject to DNS cache poisoning
      attacks by forging a large number of queries and leveraging the
      birthday paradox.

   March 2007:
      [Klein2007c] finds that Microsoft Windows DNS Server generates
      predictable Query ID values.

   October 2007:
      [Klein2007] finds that OpenBSD's DNS software (based on ISC's the BIND
      DNS Server) server of the Internet Systems Consortium (ISC)) generates
      predictable Query DNS ID values.

   January 2009:
      [RFC5452] is published, requiring resolvers to randomize the Query DNS
      ID of DNS queries, queries and to verify that the Query DNS ID of a DNS reply matches
      that of the DNS query as part of the DNS reply validation process.

   May 2010:
      [Economou2010] finds that the Windows SMTP Service implements its
      own DNS resolver that results in predictable Query DNS ID values.
      Additionally, it fails to validate that the Query DNS ID of DNS a reply
      matches the one from that of the DNS query that supposedly elicited the
      reply. it.

5.  Conclusions

   For more than 30 years, a large number of implementations of the IETF
   protocols have been subject to a variety of attacks, with effects
   ranging from Denial of Service (DoS) or data injection, injection to information
   leakages that could be exploited for pervasive monitoring [RFC7258].
   The root cause of these issues has been, in many cases, the poor
   selection of transient numeric identifiers, identifiers in such protocols, usually
   as a result of insufficient or misleading specifications.

   While it is generally possible to identify an algorithm that can
   satisfy the interoperability requirements for a given transient
   numeric identifier, this document provides empirical evidence that
   doing so without negatively affecting the security or and/or privacy
   properties of the aforementioned protocols is non-trivial. nontrivial.  It is thus
   evident that advice in this area is warranted.

   [I-D.gont-numeric-ids-sec-considerations]

   [RFC9416] aims at requiring future IETF protocol specifications to
   contain analysis of the security and privacy properties of any
   transient numeric identifiers specified by the protocol, protocol and to
   recommend an algorithm for the generation of such transient numeric
   identifiers.
   [I-D.irtf-pearg-numeric-ids-generation]  [RFC9415] specifies a number of sample algorithms for
   generating transient numeric identifiers with specific
   interorability
   interoperability requirements and failure severities.

6.  IANA Considerations

   There are

   This document has no IANA registries within this document. actions.

7.  Security Considerations

   This document analyzes the timeline of the specification and
   implementation of the transient numeric identifiers of some sample
   IETF protocols, protocols and how the security and privacy properties of such
   protocols have been affected as a result of it.  It provides concrete
   evidence that advice in this area is warranted.

   [I-D.gont-numeric-ids-sec-considerations]

   [RFC9415] analyzes and categorizes transient numeric identifiers
   based on their interoperability requirements and their associated
   failure severities and recommends possible algorithms that can be
   employed to comply with those requirements without negatively
   affecting the security and privacy properties of the corresponding
   protocols.

   [RFC9416] formally requires IETF protocol specifications to specify
   the interoperability requirements for their transient numeric
   identifiers, to do a warranted vulnerability assessment of such
   transient numeric identifiers, and to recommend possible algorithms
   for their generation, such that the interoperability requirements are
   complied with, while any negative security and or privacy properties of
   these transient numeric identifiers are mitigated.

   [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes
   transient numeric identifiers based on their interoperability
   requirements and their associated failure severities, and recommends
   possible algorithms that can comply with those requirements without
   negatively affecting the security and privacy properties of the
   corresponding protocols.

8.  Acknowledgements

   The authors would like to thank (in alphabetical order) Bernard
   Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson,
   Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris
   Shrishak, Joe Touch, Brian Trammell, and Christopher Wood, for
   providing valuable comments on earlier versions of this document.

   The authors would like to thank (in alphabetical order) Steven
   Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
   providing valuable comments on [I-D.gont-predictable-numeric-ids], on
   which this document is based.

   Section 4.2 of this document borrows text from [RFC6528], authored by
   Fernando Gont and Steven Bellovin.

   The authors would like to thank Sara Dickinson and Christopher Wood,
   for their guidance during the publication process of this document.

   The authors would like to thank Diego Armando Maradona for his magic
   and inspiration.

9.  References

9.1.

8.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", RFC 793,
              DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC6528]  Gont, F.

   [RFC1323]  Jacobson, V., Braden, R., and S. Bellovin, "Defending against Sequence
              Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
              2012, <https://www.rfc-editor.org/info/rfc6528>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, D. Borman, "TCP Extensions
              for High Performance", RFC 791, 1323, DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>. 10.17487/RFC1323, May
              1992, <https://www.rfc-editor.org/info/rfc1323>.

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
              December 1995, <https://www.rfc-editor.org/info/rfc1883>.

   [RFC2460]  Deering, S. and R.

   [RFC1884]  Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

   [RFC8200]  Deering, S. R., Ed. and R. Hinden, "Internet Protocol, S. Deering, Ed., "IP Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6",
              Addressing Architecture", RFC 3041, 1884, DOI 10.17487/RFC3041, January 2001,
              <https://www.rfc-editor.org/info/rfc3041>. 10.17487/RFC1884,
              December 1995, <https://www.rfc-editor.org/info/rfc1884>.

   [RFC2073]  Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
              Postel, "An IPv6 Provider-Based Unicast Address Format",
              RFC 2073, DOI 10.17487/RFC2073, January 1997,
              <https://www.rfc-editor.org/info/rfc2073>.

   [RFC2374]  Hinden, R., O'Dell, M., and S. Deering, "An IPv6
              Aggregatable Global Unicast Address Format", RFC 2374,
              DOI 10.17487/RFC2374, July 1998,
              <https://www.rfc-editor.org/info/rfc2374>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              DOI 10.17487/RFC3041, January 2001,
              <https://www.rfc-editor.org/info/rfc3041>.

   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
              Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
              August 2003, <https://www.rfc-editor.org/info/rfc3587>.

   [RFC1884]  Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
              Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
              December 1995, <https://www.rfc-editor.org/info/rfc1884>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC2373]  Hinden,

   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
              Resilient against Forged Answers", RFC 5452,
              DOI 10.17487/RFC5452, January 2009,
              <https://www.rfc-editor.org/info/rfc5452>.

   [RFC6056]  Larsen, M. and S. Deering, "IP Version 6 Addressing
              Architecture", F. Gont, "Recommendations for Transport-
              Protocol Port Randomization", BCP 156, RFC 2373, 6056,
              DOI 10.17487/RFC2373, July 1998,
              <https://www.rfc-editor.org/info/rfc2373>.

   [RFC4862]  Thomson, S., Narten, T., 10.17487/RFC6056, January 2011,
              <https://www.rfc-editor.org/info/rfc6056>.

   [RFC6528]  Gont, F. and T. Jinmei, "IPv6 S. Bellovin, "Defending against Sequence
              Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
              2012, <https://www.rfc-editor.org/info/rfc6528>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address Autoconfiguration",
              Autoconfiguration (SLAAC)", RFC 4862, 7217,
              DOI 10.17487/RFC4862, 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, Ed., "TCP Extensions for High Performance",
              RFC 7323, DOI 10.17487/RFC7323, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>. 2014,
              <https://www.rfc-editor.org/info/rfc7323>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

   [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
              1992, <https://www.rfc-editor.org/info/rfc1323>.

   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol Port Randomization", BCP 156, RFC 6056,
              DOI 10.17487/RFC6056, January 2011,
              <https://www.rfc-editor.org/info/rfc6056>.

   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
              Resilient against Forged Answers", (TCP)",
              STD 7, RFC 5452, 9293, DOI 10.17487/RFC5452, January 2009,
              <https://www.rfc-editor.org/info/rfc5452>.

9.2. 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

8.2.  Informative References

   [OpenBSD-PR]
              OpenBSD, "Implementation of port randomization", 29 July
              1996, <https://cvsweb.openbsd.org/src/sys/netinet/
              in_pcb.c?rev=1.6>.

   [VU-800113]
              CERT/CC, "Multiple DNS implementations vulnerable to cache
              poisoning (Vulnerability Note VU#800113)", 8 July 2008,
              <https://www.kb.cert.org/vuls/id/800113>.

   [IANA-PROT]
              IANA, "Protocol Registries",
              <https://www.iana.org/protocols>.

   [RFC5157]  Chown, T., "IPv6 Implications

   [Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and
              Solutions", April 1997,
              <http://www.openbsd.org/advisories/sni_12_resolverid.txt>.

   [Bellovin1989]
              Bellovin, S., "Security Problems in the TCP/IP Protocol
              Suite", Computer Communications Review, vol. 19, no. 2,
              pp. 32-48, April 1989,
              <https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.

   [Bellovin2002]
              Bellovin, S., "A Technique for Network Scanning",
              RFC 5157, Counting NATted Hosts",
              IMW'02, Marseille, France, DOI 10.17487/RFC5157, March 2008,
              <https://www.rfc-editor.org/info/rfc5157>.

   [RFC8981] 10.1145/637201.637243,
              November 2002,
              <https://www.cs.columbia.edu/~smb/papers/fnat.pdf>.

   [CERT2001] CERT/CC, "CERT Advisory CA-2001-09: Statistical Weaknesses
              in TCP/IP Initial Sequence Numbers", May 2001,
              <https://resources.sei.cmu.edu/asset_files/
              WhitePaper/2001_019_001_496192.pdf>.

   [draft-cooper-6man-ipv6-address-generation-privacy-00]
              Cooper, A., Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions D. Thaler, "Privacy
              Considerations for Stateless IPv6 Address
              Autoconfiguration Generation Mechanisms",
              Work in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,
              <https://www.rfc-editor.org/info/rfc8981>.

   [I-D.ietf-6man-rfc4941bis] Progress, Internet-Draft, draft-cooper-6man-ipv6-
              address-generation-privacy-00, 15 July 2013,
              <https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-
              address-generation-privacy-00.txt>.

   [draft-eddy-rfc793bis-04]
              Eddy, W., Ed., "Transmission Control Protocol
              Specification", Work in Progress, Internet-Draft, draft-
              eddy-rfc793bis-04, 25 August 2014,
              <https://www.ietf.org/archive/id/draft-eddy-rfc793bis-
              04.txt>.

   [draft-fgont-6man-rfc4941bis-00]
              Gont, F., Krishnan, S., Narten, T., and R. P. Draves,
              "Temporary Address
              "Privacy Extensions for Stateless Address
              Autoconfiguration in IPv6", Work in Progress, Internet-
              Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020,
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              rfc4941bis-12.txt>.

   [I-D.gont-opsec-ipv6-host-scanning] draft-fgont-6man-rfc4941bis-00, 25 March 2018,
              <https://www.ietf.org/archive/id/draft-fgont-6man-
              rfc4941bis-00.txt>.

   [draft-gont-6man-address-usage-recommendations-00]
              Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", W. LIU, "IPv6 Address Usage Recommendations",
              Work in Progress, Internet-Draft, draft-gont-
              opsec-ipv6-host-scanning-02, 22 October 2012,
              <https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-
              host-scanning-02.txt>.

   [I-D.ietf-opsec-ipv6-host-scanning] draft-gont-6man-address-
              usage-recommendations-00, 27 May 2016,
              <https://www.ietf.org/archive/id/draft-gont-6man-address-
              usage-recommendations-00.txt>.

   [draft-gont-6man-non-stable-iids-00]
              Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", Work in Progress, Internet-Draft, draft-ietf-
              opsec-ipv6-host-scanning-08, 28 August 2015,
              <https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-
              host-scanning-08.txt>.

   [I-D.gont-6man-stable-privacy-addresses]
              Gont, F., "A method for Generating Stable Privacy-Enhanced
              Addresses with W. Liu, "Recommendation on Non-Stable IPv6 Stateless Address Autoconfiguration
              (SLAAC)", Work in Progress, Internet-Draft, draft-gont-
              6man-stable-privacy-addresses-01, 31 March 2012,
              <https://www.ietf.org/archive/id/draft-gont-6man-stable-
              privacy-addresses-01.txt>.

   [I-D.ietf-6man-stable-privacy-addresses]
              Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", Identifiers", Work in Progress, Internet-
              Draft, draft-ietf-6man-stable-privacy-addresses-17, 27
              January 2014, <https://www.ietf.org/archive/id/draft-ietf-
              6man-stable-privacy-addresses-17.txt>.

   [I-D.cooper-6man-ipv6-address-generation-privacy]
              Cooper, A., Internet-Draft,
              draft-gont-6man-non-stable-iids-00, 23 May 2016,
              <https://www.ietf.org/archive/id/draft-gont-6man-non-
              stable-iids-00.txt>.

   [draft-gont-6man-predictable-fragment-id-00]
              Gont, F., and D. Thaler, "Privacy
              Considerations for IPv6 Address Generation Mechanisms", "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft, draft-cooper-6man-ipv6-
              address-generation-privacy-00,
              draft-gont-6man-predictable-fragment-id-00, 15 July 2013,
              <https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-
              address-generation-privacy-00.txt>.

   [I-D.ietf-6man-ipv6-address-generation-privacy]
              Cooper, A., December
              2011, <https://www.ietf.org/archive/id/draft-gont-6man-
              predictable-fragment-id-00.txt>.

   [draft-gont-6man-predictable-fragment-id-03]
              Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms", Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
              address-generation-privacy-08, 23 September 2015,
              <https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-
              address-generation-privacy-08.txt>.

   [Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
              (help wanted!)", Message posted to the IPv6 Hackers
              mailing-list Message-ID:
              <51184548.3030105@si6networks.com>,
              draft-gont-6man-predictable-fragment-id-03, 9 January
              2013,
              <https://lists.si6networks.com/pipermail/
              ipv6hackers/2013-February/000947.html>.

   [IPv6-Toolkit]
              SI6 Networks, "SI6 Networks' IPv6 Toolkit",
              <https://www.si6networks.com/tools/ipv6toolkit>. <https://www.ietf.org/archive/id/draft-gont-6man-
              predictable-fragment-id-03.txt>.

   [draft-gont-6man-stable-privacy-addresses-00]
              Gont, F., "A method for Generating Stable Privacy-Enhanced
              Addresses with IPv6 Stateless Address Autoconfiguration
              (SLAAC)", Work in Progress, Internet-Draft, draft-gont-
              6man-stable-privacy-addresses-00, 15 December 2011,
              <https://tools.ietf.org/id/draft-gont-6man-stable-privacy-
              addresses-00.txt>.

   [draft-ietf-6man-stable-privacy-addresses-00]
              <https://www.ietf.org/archive/id/draft-gont-6man-stable-
              privacy-addresses-00.txt>.

   [draft-gont-6man-stable-privacy-addresses-01]
              Gont, F., "A method for Generating Stable Privacy-Enhanced
              Addresses with IPv6 Stateless Address Autoconfiguration
              (SLAAC)", Work in Progress, Internet-Draft, draft-ietf-
              6man-stable-privacy-addresses-00, 18 May draft-gont-
              6man-stable-privacy-addresses-01, 31 March 2012,
              <https://tools.ietf.org/id/draft-ietf-6man-stable-privacy-
              addresses-00.txt>.

   [draft-gont-6man-address-usage-recommendations-00]
              <https://www.ietf.org/archive/id/draft-gont-6man-stable-
              privacy-addresses-01.txt>.

   [draft-gont-ntp-port-randomization-00]
              Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", G. Gont, "Port Randomization in the Network
              Time Protocol Version 4", Work in Progress, Internet-Draft, draft-gont-6man-address-
              usage-recommendations-00, 27 May 2016,
              <https://tools.ietf.org/id/draft-gont-6man-address-usage-
              recommendations-00.txt>.

   [draft-gont-6man-non-stable-iids-00] Internet-
              Draft, draft-gont-ntp-port-randomization-00, 16 April
              2019, <https://www.ietf.org/archive/id/draft-gont-ntp-
              port-randomization-00.txt>.

   [draft-gont-opsec-ipv6-host-scanning-02]
              Gont, F. and W. Liu, "Recommendation on Non-Stable T. Chown, "Network Reconnaissance in IPv6
              Interface Identifiers",
              Networks", Work in Progress, Internet-Draft,
              draft-gont-6man-non-stable-iids-00, draft-gont-
              opsec-ipv6-host-scanning-02, 23 May 2016,
              <https://tools.ietf.org/id/draft-gont-6man-non-stable-
              iids-00.txt>. October 2012,
              <https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-
              host-scanning-02.txt>.

   [draft-gont-predictable-numeric-ids-03]
              Gont, F. and I. Arce, "Security and Privacy Implications
              of Numeric Identifiers Employed in Network Protocols",
              Work in Progress, Internet-Draft, draft-gont-predictable-
              numeric-ids-03, 11 March 2019,
              <https://datatracker.ietf.org/doc/html/draft-gont-
              predictable-numeric-ids-03>.

   [draft-ietf-6man-default-iids-00]
              Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              Work in Progress, Internet-Draft, draft-ietf-6man-default-
              iids-00, 28 July 24 January 2014, <https://tools.ietf.org/id/draft-
              ietf-6man-default-iids-00.txt>.

   [RFC8064]
              <https://www.ietf.org/archive/id/draft-ietf-6man-default-
              iids-00.txt>.

   [draft-ietf-6man-default-iids-16]
              Gont, F., Cooper, A., Thaler, D., and W. Liu, LIU,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February
              Work in Progress, Internet-Draft, draft-ietf-6man-default-
              iids-16, 28 September 2016,
              <https://www.ietf.org/archive/id/draft-ietf-6man-default-
              iids-16.txt>.

   [draft-ietf-6man-ipv6-address-generation-privacy-08]
              Cooper, A., Gont, F., and D. Thaler, "Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
              address-generation-privacy-08, 23 September 2015,
              <https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-
              address-generation-privacy-08.txt>.

   [draft-ietf-6man-predictable-fragment-id-00]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-00, 22 March 2013,
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              predictable-fragment-id-00.txt>.

   [draft-ietf-6man-predictable-fragment-id-01]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-01, 29 April 2014,
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              predictable-fragment-id-01.txt>.

   [draft-ietf-6man-predictable-fragment-id-02]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-02, 19 December
              2014, <https://datatracker.ietf.org/doc/html/draft-ietf-
              6man-predictable-fragment-id-02>.

   [draft-ietf-6man-predictable-fragment-id-08]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-08, 9 June 2015,
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              predictable-fragment-id-08.txt>.

   [draft-ietf-6man-predictable-fragment-id-10]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-10, 9 October
              2015, <https://www.ietf.org/archive/id/draft-ietf-6man-
              predictable-fragment-id-10.txt>.

   [draft-ietf-6man-rfc2460bis-05]
              Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", Work in Progress, Internet-Draft,
              draft-ietf-6man-rfc2460bis-05, 28 June 2016,
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              rfc2460bis-05.txt>.

   [draft-ietf-6man-rfc2460bis-13]
              Deering, S. and R. Hinden, "draft-ietf-6man-rfc2460bis-
              13", Work in Progress, Internet-Draft, draft-ietf-6man-
              rfc2460bis-13, 19 May 2017,
              <https://www.rfc-editor.org/info/rfc8064>.
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              rfc2460bis-13.txt>.

   [draft-ietf-6man-rfc4941bis-00]
              Gont, F., Krishnan, S.K., S., Narten, T.N., T., and R.D. R. Draves,
              "Privacy Extensions for Stateless Address
              Autoconfiguration in IPv6", Work in Progress, Internet-
              Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018,
              <https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-
              00.txt>.

   [draft-fgont-6man-rfc4941bis-00]
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              rfc4941bis-00.txt>.

   [draft-ietf-6man-rfc4941bis-12]
              Gont, F., Krishnan, S.K., S., Narten, T.N., T., and R.D. R. Draves,
              "Privacy
              "Temporary Address Extensions for Stateless Address
              Autoconfiguration in IPv6", Work in Progress, Internet-
              Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018,
              <https://tools.ietf.org/id/draft-fgont-6man-rfc4941bis-
              00.txt>.

   [I-D.ietf-6man-default-iids] draft-ietf-6man-rfc4941bis-12, 2 November 2020,
              <https://www.ietf.org/archive/id/draft-ietf-6man-
              rfc4941bis-12.txt>.

   [draft-ietf-6man-stable-privacy-addresses-00]
              Gont, F., Cooper, A., Thaler, D., and W. S. LIU,
              "Recommendation on "A method for Generating Stable Privacy-Enhanced
              Addresses with IPv6 Interface Identifiers", Stateless Address Autoconfiguration
              (SLAAC)", Work in Progress, Internet-Draft, draft-ietf-6man-default-
              iids-16, 28 September 2016,
              <https://www.ietf.org/archive/id/draft-ietf-6man-default-
              iids-16.txt>.

   [RFC7721]  Cooper, A., draft-ietf-
              6man-stable-privacy-addresses-00, 18 May 2012,
              <https://www.ietf.org/archive/id/draft-ietf-6man-stable-
              privacy-addresses-00.txt>.

   [draft-ietf-6man-stable-privacy-addresses-17]
              Gont, F., and D. Thaler, "Security and Privacy
              Considerations "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.rfc-editor.org/info/rfc7721>.

   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance
              Autoconfiguration (SLAAC)", Work in IPv6
              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
              <https://www.rfc-editor.org/info/rfc7707>.

   [I-D.gont-predictable-numeric-ids] Progress, Internet-
              Draft, draft-ietf-6man-stable-privacy-addresses-17, 27
              January 2014, <https://www.ietf.org/archive/id/draft-ietf-
              6man-stable-privacy-addresses-17.txt>.

   [draft-ietf-ntp-port-randomization-00]
              Gont, F. and I. Arce, "Security F., Gont, G., and Privacy Implications
              of Numeric Identifiers Employed M. Lichvar, "Port Randomization in
              the Network Protocols", Time Protocol Version 4", Work in Progress, Internet-Draft, draft-gont-predictable-
              numeric-ids-03, 11 March
              October 2019,
              <https://www.ietf.org/archive/id/draft-gont-predictable-
              numeric-ids-03.txt>.

   [I-D.gont-numeric-ids-sec-considerations] <https://www.ietf.org/archive/id/draft-ietf-
              ntp-port-randomization-00.txt>.

   [draft-ietf-ntp-port-randomization-08]
              Gont, F. F., Gont, G., and I. Arce, "Security Considerations for
              Transient Numeric Identifiers Employed M. Lichvar, "Port Randomization in
              the Network
              Protocols", Time Protocol Version 4", Work in Progress, Internet-Draft, draft-gont-
              numeric-ids-sec-considerations-08, 10 December 2022,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              gont-numeric-ids-sec-considerations/>.

   [I-D.irtf-pearg-numeric-ids-generation]
              Gont, F.
              June 2021, <https://www.ietf.org/archive/id/draft-ietf-
              ntp-port-randomization-08.txt>.

   [draft-ietf-ntp-refid-updates-00]
              Stenn, H. and I. Arce, "On the Generation of Transient
              Numeric Identifiers", S. Goldberg, "Network Time Protocol REFID
              Updates", Work in Progress, Internet-Draft,
              draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022,
              <https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-
              ids-generation-11.txt>.

   [I-D.ietf-6man-rfc2460bis]
              Deering, S. E. draft-ietf-
              ntp-refid-updates-00, 13 November 2016,
              <https://www.ietf.org/archive/id/draft-ietf-ntp-refid-
              updates-00.txt>.

   [draft-ietf-opsec-ipv6-host-scanning-08]
              Gont, F. and R. M. Hinden, "Internet Protocol,
              Version 6 (IPv6) Specification", T. Chown, "Network Reconnaissance in IPv6
              Networks", Work in Progress, Internet-Draft, draft-ietf-6man-rfc2460bis-13, 19 May
              2017, <https://www.ietf.org/archive/id/draft-ietf-6man-
              rfc2460bis-13.txt>. draft-ietf-
              opsec-ipv6-host-scanning-08, 28 August 2015,
              <https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-
              host-scanning-08.txt>.

   [draft-stenn-ntp-not-you-refid-00]
              Goldberg, S. and H. Stenn, "Network Time Protocol Not You
              REFID", Work in Progress, Internet-Draft, draft-stenn-ntp-
              not-you-refid-00, 8 July 2016, <https://tools.ietf.org/id/
              draft-stenn-ntp-not-you-refid-00.txt>.

   [draft-ietf-ntp-refid-updates-00]
              Goldberg, S.
              <https://www.ietf.org/archive/id/draft-stenn-ntp-not-you-
              refid-00.txt>.

   [Economou2010]
              Economou, N., "Windows SMTP Service DNS query Id
              vulnerabilities", Advisory ID Internal CORE-2010-0427, May
              2010, <https://www.coresecurity.com/core-labs/advisories/
              core-2010-0424-windows-smtp-dns-query-id-bugs>.

   [Fyodor2002]
              Fyodor, "Idle scanning and H. Stenn, "Network Time Protocol Not You
              REFID", Work in Progress, Internet-Draft, draft-ietf-ntp-
              refid-updates-00, 13 November 2016,
              <https://tools.ietf.org/id/draft-ietf-ntp-refid-updates-
              00.txt>. related IP ID games", September
              2002,
              <https://nmap.org/presentations/CanSecWest03/CD_Content/
              idlescan_paper/idlescan.html>.

   [Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
              05", Post message to the IETF NTP WG mailing list Message-ID:
              <d871d66d-4043-d8d0-f924-2191ebb2e2ce@si6networks.com>, list, 16 April 2019,
              <https://mailarchive.ietf.org/arch/msg/ntp/
              NkfTHxUUOdp14Agh3h1IPqfcRRg>.

   [I-D.ietf-ntp-refid-updates]
              Stenn, H. and S. Goldberg, "Network Time Protocol REFID
              Updates", Work

   [Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack
              In Paris 2011 Conference, Paris, France, June 2011,
              <https://www.si6networks.com/files/presentations/hip2011/
              fgont-hip2011-hacking-ipv6-networks.pdf>.

   [Gont2012] Gont, F., "Recent Advances in Progress, Internet-Draft, draft-ietf-
              ntp-refid-updates-05, 25 March 2019,
              <https://www.ietf.org/archive/id/draft-ietf-ntp-refid-
              updates-05.txt>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol IPv6 Security", BSDCan 2012
              Conference, Ottawa, Canada, May 2012,
              <https://www.si6networks.com/files/presentations/
              bsdcan2012/fgont-bsdcan2012-recent-advances-in-
              ipv6-security.pdf>.

   [Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
              (help wanted!)", message to the IPv6 Hackers mailing list,
              11 February 2013,
              <https://lists.si6networks.com/pipermail/
              ipv6hackers/2013-February/000947.html>.

   [IANA-PROT]
              IANA, "Protocol Registries",
              <https://www.iana.org/protocols>.

   [IPID-DEV] Klein, A. and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC7258]  Farrell, S. B. Pinkas, "From IP ID to Device ID and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948,
              KASLR Bypass (Extended Version)",
              DOI 10.17487/RFC1948, May 1996,
              <https://www.rfc-editor.org/info/rfc1948>.

   [Wright1994]
              Wright, G.R. and W.R. Stevens, "TCP/IP Illustrated, Volume
              2: 10.48550/arXiv.1906.10478, October 2019,
              <https://arxiv.org/pdf/1906.10478.pdf>.

   [IPv6-Toolkit]
              SI6 Networks, "IPv6 Toolkit",
              <https://www.si6networks.com/tools/ipv6toolkit>.

   [Kaminsky2008]
              Kaminsky, D., "Black Ops 2008: It's The Implementation", Addison-Wesley, 1994.

   [Zalewski2001]
              Zalewski, M., "Strange Attractors End Of The Cache
              As We Know It", August 2008,
              <https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-
              Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf>.

   [Klein2007]
              Klein, A., "OpenBSD DNS Cache Poisoning and TCP/IP Sequence
              Number Analysis", 2001,
              <https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.

   [Zalewski2002]
              Zalewski, Multiple O/S
              Predictable IP ID Vulnerability", October 2007,
              <https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
              DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
              erability.pdf>.

   [Klein2007b]
              Klein, A., "BIND 9 DNS Cache Poisoning", March 2007,
              <https://citeseerx.ist.psu.edu/doc/10.1.1.86.4474>.

   [Klein2007c]
              Klein, A., "Windows DNS Server Cache Poisoning", March
              2007, <https://dl.packetstormsecurity.net/papers/attack/
              Windows_DNS_Cache_Poisoning.pdf>.

   [Morbitzer2013]
              Morbitzer, M., "Strange Attractors and TCP/IP Sequence
              Number Analysis - One Year Later", 2001,
              <https://lcamtuf.coredump.cx/newtcp/>.

   [Bellovin1989]
              Bellovin, S., "Security Problems "[PATCH] TCP Idle Scan in IPv6", message to
              the TCP/IP Protocol
              Suite", Computer Communications Review, vol. 19, no. 2,
              pp. 32-48, 1989,
              <https://www.cs.columbia.edu/~smb/papers/ipext.pdf>. nmap-dev mailing list, 3 June 2013,
              <https://seclists.org/nmap-dev/2013/q2/394>.

   [Morris1985]
              Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
              Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
              NJ, February 1985,
              <https://pdos.csail.mit.edu/~rtm/papers/117.pdf>.

   [USCERT2001]
              US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple
              TCP/IP implementations may use statistically predictable
              initial sequence numbers", 2001,
              <https://www.kb.cert.org/vuls/id/498440>.

   [CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
              TCP/IP Initial Sequence Numbers", 2001,
              <https://resources.sei.cmu.edu/asset_files/
              WhitePaper/2001_019_001_496192.pdf>.

   [Shimomura1995]
              Shimomura, T., "Technical details

   [NIST-NTP] Sherman, J. and J. Levine, "Usage Analysis of the attack described
              by Markoff in NYT", Message posted in USENET's
              comp.security.misc newsgroup Message-ID:
              <3g5gkl$5j1@ariel.sdsc.edu>, 1995,
              <https://www.gont.com.ar/docs/post-shimomura-usenet.txt>.

   [I-D.eddy-rfc793bis-04]
              Eddy, W., "Transmission Control Protocol Specification",
              Work in Progress, Internet-Draft, draft-eddy-rfc793bis-04,
              25 August 2014,
              <https://tools.ietf.org/id/draft-eddy-rfc793bis-04.txt>.

   [OpenBSD-TCP-ISN-I]
              OpenBSD, "Implementation of TCP ISN randomization based on
              random increments", 29 July 1996,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              tcp_subr.c?rev=1.6>.

   [OpenBSD-TCP-ISN-R]
              OpenBSD, "Implementation NIST
              Internet Time Service", Journal of TCP ISN randomization based on
              simple randomization", 13 December 2000,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              tcp_subr.c?rev=1.37>.

   [OpenBSD-TCP-ISN-H]
              OpenBSD, "Implementation Research of RFC1948 for TCP ISN
              randomization", 13 December 2000,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              tcp_subr.c?rev=1.97>.

   [I-D.gont-ntp-port-randomization]
              Gont, F. and G. Gont, "Port Randomization in the Network
              Time Protocol Version 4", Work in Progress, Internet-
              Draft, draft-gont-ntp-port-randomization-04, 6 August
              2019, <https://www.ietf.org/archive/id/draft-gont-ntp-
              port-randomization-04.txt>.

   [I-D.ietf-ntp-port-randomization]
              Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
              Version 4: Port Randomization", Work in Progress,
              June 2021, <https://www.ietf.org/archive/id/draft-ietf-
              ntp-port-randomization-08.txt>.

   [RFC9109]  Gont, F., Gont, G.,
              National Institute of Standards and M. Lichvar, "Network Time Protocol
              Version 4: Port Randomization", RFC 9109,
              DOI 10.17487/RFC9109, August 2021,
              <https://www.rfc-editor.org/info/rfc9109>. Technology, Volume
              121, March 2016,
              <https://tf.nist.gov/general/pdf/2818.pdf>.

   [NTP-PORTR]
              Gont, F., "[Ntp] New rev of the NTP port randomization I-D
              (Fwd: New Version Notification for draft-gont-ntp-port-
              randomization-01.txt)", message to the IETF NTP mailing
              list, 21 May 2019,
              <https://mailarchive.ietf.org/arch/browse/
              ntp/?gbt=1&index=n09Sb61WkH03lSRtamkELXwEQN4>.

   [NIST-NTP] Sherman, J.A. and J. Levine, "Usage Analysis
              <https://mailarchive.ietf.org/arch/msg/ntp/
              xSCu5Vhb3zoWcqEjUMmzP8pOdW4/>.

   [OpenBSD-IPv4-ID]
              OpenBSD, "Randomization of the NIST
              Internet Time Service", Journal of Research IPv4 Identification field",
              December 1998,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              ip_id.c?rev=1.1>.

   [OpenBSD-IPv6-ID]
              OpenBSD, "Randomization of the
              National Institute IPv6 Identification field",
              October 2003,
              <https://cvsweb.openbsd.org/src/sys/netinet6/
              ip6_id.c?rev=1.1>.

   [OpenBSD-PR]
              OpenBSD, "Implementation of Standards and Technology Volume 121,
              8 March 2016, <https://tf.nist.gov/general/pdf/2818.pdf>.

   [IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and
              KASLR Bypass (Extended Version)", port randomization", July
              1996, <https://cvsweb.openbsd.org/src/sys/netinet/
              in_pcb.c?rev=1.6>.

   [OpenBSD-TCP-ISN-H]
              OpenBSD, "Implementation of RFC1948 for TCP ISN
              randomization", June 2019,
              <https://arxiv.org/pdf/1906.10478.pdf>. 2007,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              tcp_subr.c?rev=1.97>.

   [OpenBSD-TCP-ISN-I]
              OpenBSD, "Implementation of TCP ISN randomization based on
              random increments", July 1996,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              tcp_subr.c?rev=1.6>.

   [OpenBSD-TCP-ISN-R]
              OpenBSD, "Implementation of TCP ISN randomization based on
              simple randomization", December 2000,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              tcp_subr.c?rev=1.37>.

   [RedHat2011]
              Red Hat, "RHSA-2011:1465-1 - Security Advisory", November
              2011, <https://rhn.redhat.com/errata/RHSA-2011-1465.html>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948, DOI 10.17487/RFC1948, May 1996,
              <https://www.rfc-editor.org/info/rfc1948>.

   [RFC5157]  Chown, T., "IPv6 Implications for Network Scanning",
              RFC 5157, DOI 10.17487/RFC5157, March 2008,
              <https://www.rfc-editor.org/info/rfc5157>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6274]  Gont, F., "Security Assessment of the Internet Protocol
              Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
              <https://www.rfc-editor.org/info/rfc6274>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
              <https://www.rfc-editor.org/info/rfc7707>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.rfc-editor.org/info/rfc7721>.

   [RFC7739]  Gont, F., "Security Implications of Predictable Fragment
              Identification Values", RFC 7739, DOI 10.17487/RFC7739,
              February 2016, <https://www.rfc-editor.org/info/rfc7739>.

   [Bellovin2002]
              Bellovin, S. M., "A Technique

   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February 2017,
              <https://www.rfc-editor.org/info/rfc8064>.

   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions for Counting NATted Hosts",
              IMW'02 Nov. 6-8, 2002, Marseille, France, 2002,
              <https://www.cs.columbia.edu/~smb/papers/fnat.pdf>.

   [Fyodor2002]
              Fyodor, "Idle scanning Stateless Address
              Autoconfiguration in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,
              <https://www.rfc-editor.org/info/rfc8981>.

   [RFC9109]  Gont, F., Gont, G., and related IP ID games", M. Lichvar, "Network Time Protocol
              Version 4: Port Randomization", RFC 9109,
              DOI 10.17487/RFC9109, August 2021,
              <https://www.rfc-editor.org/info/rfc9109>.

   [RFC9415]  Gont, F. and I. Arce, "On the Generation of Transient
              Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July
              2023, <https://www.rfc-editor.org/info/rfc9415>.

   [RFC9416]  Gont, F. and I. Arce, "Security Considerations for
              Transient Numeric Identifiers Employed in Network
              Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July
              2023, <https://www.rfc-editor.org/info/rfc9416>.

   [Sacramento2002]
              Sacramento, V., "CAIS-ALERT: Vulnerability in the sending
              requests control of BIND", message to the Bugtraq mailing
              list, 25 November 2002,
              <http://www.insecure.org/nmap/idlescan.html>.
              <https://seclists.org/bugtraq/2002/Nov/331>.

   [Sanfilippo1998a]
              Sanfilippo, S., "about the ip header id", Post message to the
              Bugtraq
              mailing-list, Mon Dec mailing list, 14 December 1998,
              <http://seclists.org/bugtraq/1998/Dec/48>.

   [Sanfilippo1998b]
              Sanfilippo, S., "Idle scan", Post "new tcp scan method", message to the
              Bugtraq mailing-list, mailing list, 18 December 1998, <https://github.com/antirez/hping/raw/master/docs/
              SPOOFED_SCAN.txt>.
              <https://seclists.org/bugtraq/1998/Dec/79>.

   [Sanfilippo1999]
              Sanfilippo, S., "more ip id", Post message to the Bugtraq mailing-
              mailing list, November 1999,
              <https://github.com/antirez/hping/raw/master/docs/MORE-
              FUN-WITH-IPID>.

   [Morbitzer2013]
              Morbitzer, M., "[PATCH] TCP Idle Scan

   [Schuba1993]
              Schuba, C., "Addressing Weakness in IPv6",  Message
              posted to the nmap-dev mailing-list, 2013,
              <https://seclists.org/nmap-dev/2013/q2/394>.

   [OpenBSD-IPv4-ID]
              OpenBSD, "Randomization Domain Name System
              Protocol", August 1993,
              <http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/
              schuba-DNS-msthesis.pdf>.

   [Shimomura1995]
              Shimomura, T., "Technical details of the IPv4 Identification field",
              26 December 1998,
              <https://cvsweb.openbsd.org/src/sys/netinet/
              ip_id.c?rev=1.1>.

   [OpenBSD-IPv6-ID]
              OpenBSD, "Randomization of attack described
              by Markoff in NYT", message to the IPv6 Identification field",
              1 October 2003,
              <https://cvsweb.openbsd.org/src/sys/netinet6/
              ip6_id.c?rev=1.1>. USENET
              comp.security.misc newsgroup, 25 January 1995,
              <https://www.gont.com.ar/files/post-shimomura-usenet.txt>.

   [Silbersack2005]
              Silbersack, M.J., M., "Improving TCP/IP security through
              randomization without sacrificing interoperability",
              EuroBSDCon 2005 Conference, January 2005,
              <https://citeseerx.ist.psu.edu/viewdoc/
              download?doi=10.1.1.91.4542&rep=rep1&type=pdf>.

   [Zalewski2003]
              Zalewski,

   [SUSE2011] Meissner, M., "A new TCP/IP blind data injection
              technique?", 2003,
              <https://lcamtuf.coredump.cx/ipfrag.txt>.

   [Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and
              Solutions", 1997,
              <http://www.openbsd.org/advisories/sni_12_resolverid.txt>.

   [Klein2007]
              Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
              Predictable IP ID Vulnerability", 2007,
              <https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
              DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
              erability.pdf>.

   [Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack
              In Paris 2011 Conference Paris, France, June 2011.

   [RedHat2011]
              RedHat, "RedHat "[security-announce] SUSE Security Advisory RHSA-2011:1465-1:
              Important:
              Announcement: Linux kernel security and bug fix update", update (SUSE-
              SA:2011:046)", message to the openSUSE Security Announce
              mailing list, 13 December 2011,
              <https://rhn.redhat.com/errata/RHSA-2011-1465.html>.
              <https://lists.opensuse.org/opensuse-security-
              announce/2011-12/msg00011.html>.

   [TCPT-uptime]
              McDanel, B., "TCP Timestamping - Obtaining System Uptime
              Remotely", message to the Bugtraq mailing list, March
              2001, <https://seclists.org/bugtraq/2001/Mar/182>.

   [Ubuntu2011]
              Ubuntu, "Ubuntu: USN-1253-1: "USN-1253-1: Linux kernel vulnerabilities",
              November 2011,
              <https://ubuntu.com/security/notices/USN-1253-1>.

   [SUSE2011] SUSE, "SUSE Security Announcement: Linux kernel security
              update (SUSE-SA:2011:046)", 2011,
              <https://lists.opensuse.org/opensuse-security-
              announce/2011-12/msg00011.html>.

   [Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
              Conference Ottawa, Canada. May 11-12, 2012, May 2012,
              <https://www.si6networks.com/files/presentations/
              bsdcan2012/fgont-bsdcan2012-recent-advances-in-
              ipv6-security.pdf>.

   [I-D.gont-6man-predictable-fragment-id]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-gont-6man-predictable-fragment-id-03, 9 January
              2013, <https://www.ietf.org/archive/id/draft-gont-6man-
              predictable-fragment-id-03.txt>.

   [I-D.ietf-6man-predictable-fragment-id]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-10, 9 October
              2015, <https://www.ietf.org/archive/id/draft-ietf-6man-
              predictable-fragment-id-10.txt>.

   [draft-ietf-6man-predictable-fragment-id-01]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-01, 30 April 2014,
              <https://tools.ietf.org/id/draft-ietf-6man-predictable-
              fragment-id-01.txt>.

   [draft-ietf-6man-predictable-fragment-id-02]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-02, 19 December
              2014, <https://tools.ietf.org/id/draft-ietf-6man-
              predictable-fragment-id-02.txt>.

   [draft-gont-6man-predictable-fragment-id-00]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-gont-6man-predictable-fragment-id-00, 15 December
              2011, <https://tools.ietf.org/id/draft-gont-6man-
              predictable-fragment-id-00.txt>.

   [draft-ietf-6man-predictable-fragment-id-00]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-00, 22

   [USCERT2001]
              CERT CC, "Multiple TCP/IP implementations may use
              statistically predictable initial sequence numbers",
              Vulnerability Note VU#498440, March 2013,
              <https://tools.ietf.org/id/draft-ietf-6man-predictable-
              fragment-id-00.txt>.

   [draft-ietf-6man-predictable-fragment-id-08]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, Internet-Draft,
              draft-ietf-6man-predictable-fragment-id-08, 9 June 2015,
              <https://tools.ietf.org/id/draft-ietf-6man-predictable-
              fragment-id-08.txt>.

   [Schuba1993]
              Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME
              SYSTEM PROTOCOL", 1993,
              <http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/
              schuba-DNS-msthesis.pdf>. 2001,
              <https://www.kb.cert.org/vuls/id/498440>.

   [Vixie1995]
              Vixie, P., "DNS and BIND Security Issues", 5th Usenix
              Security Symposium May 2, 1995, 2 May Symposium, June 1995, <https://www.u
              senix.org/legacy/publications/library/proceedings/
              security95/full_papers/vixie.pdf>.

   [Klein2007b]
              Klein, A., "BIND 9 DNS Cache Poisoning", March 2007,
              <https://citeseerx.ist.psu.edu/viewdoc/
              summary?doi=10.1.1.86.4474>.

   [Klein2007c]
              Klein, A., "Windows <https://www.usenix.org/leg
              acy/publications/library/proceedings/security95/
              full_papers/vixie.pdf>.

   [VU-800113]
              CERT/CC, "Multiple DNS Server Cache Poisoning", March
              2007, <https://dl.packetstormsecurity.net/papers/attack/
              Windows_DNS_Cache_Poisoning.pdf>.

   [Sacramento2002]
              Sacramento, V., "CAIS-ALERT: implementations vulnerable to cache
              poisoning", Vulnerability in the sending
              requests control of BIND", 19 November Note VU#800113, July 2008,
              <https://www.kb.cert.org/vuls/id/800113>.

   [Wright1994]
              Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
              The Implementation", Addison-Wesley, February 1995.

   [Zalewski2001]
              Zalewski, M., "Strange Attractors and TCP/IP Sequence
              Number Analysis (2001)", March 2001,
              <https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.

   [Zalewski2002]
              Zalewski, M., "Strange Attractors and TCP/IP Sequence
              Number Analysis - One Year Later (2002)", 2002,
              <https://seclists.org/bugtraq/2002/Nov/331>.

   [Kaminsky2008]
              Kaminsky, D., "Black Ops 2008: It's
              <https://lcamtuf.coredump.cx/newtcp/>.

   [Zalewski2003]
              Zalewski, M., "A new TCP/IP blind data injection
              technique?", December 2003,
              <https://lcamtuf.coredump.cx/ipfrag.txt>.

Acknowledgements

   The End Of authors would like to thank (in alphabetical order) Bernard
   Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson,
   Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris
   Shrishak, Joe Touch, Brian Trammell, and Christopher Wood for
   providing valuable comments on earlier versions of this document.

   The Cache
              As We Know It", August 2008,
              <https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-
              Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf>.

   [Economou2010]
              Economou, N., "Windows SMTP Service DNS query Id
              vulnerabilities", Advisory ID Internal CORE-2010-0427 May
              4, 2010, 4 May 2010, <https://www.coresecurity.com/core-
              labs/advisories/core-2010-0424-windows-smtp-dns-query-id-
              bugs>. authors would like to thank (in alphabetical order) Steven
   Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson for
   providing valuable comments on
   [draft-gont-predictable-numeric-ids-03], on which this document is
   based.

   Section 4.2 of this document borrows text from [RFC6528], authored by
   Fernando Gont and Steven Bellovin.

   The authors would like to thank Sara Dickinson and Christopher Wood
   for their guidance during the publication process of this document.

   The authors would like to thank Diego Armando Maradona for his magic
   and inspiration.

Authors' Addresses

   Fernando Gont
   SI6 Networks
   Segurola y Habana
   4310 7mo piso
   Ciudad Autonoma de Buenos Aires
   Buenos Aires
   Argentina
   Email: fgont@si6networks.com
   URI:   https://www.si6networks.com

   Ivan Arce
   Quarkslab
   Segurola y Habana
   4310 7mo piso
   Ciudad Autonoma de Buenos Aires Buenos Aires
   Argentina
   Email: iarce@quarkslab.com
   URI:   https://www.quarkslab.com