Network Working Group

Internet Engineering Task Force (IETF)                           F. Gont
Internet-Draft
Request for Comments: 9416                                  SI6 Networks
Updates: 3552 (if approved)
BCP: 72                                                          I. Arce
Intended status:
Updates: 3552                                                  Quarkslab
Category: Best Current Practice                         Quarkslab
Expires: 31                                July 2023                                    27 January 2023
ISSN: 2070-1721

 Security Considerations for Transient Numeric Identifiers Employed in
                           Network Protocols
              draft-gont-numeric-ids-sec-considerations-11

Abstract

   Poor selection of transient numerical identifiers in protocols such
   as the TCP/IP suite has historically led to a number of attacks on
   implementations, ranging from Denial of Service (DoS) to or data
   injection and to information leakage leakages that can be exploited by pervasive
   monitoring.  Due diligence in the specification of transient numeric
   identifiers is required even when cryptographic techniques are
   employed, since these techniques might not mitigate all the
   associated issues.  This document formally updates RFC 3552,
   incorporating requirements for transient numeric identifiers, to
   prevent flaws in future protocols and implementations.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 7841.

   Information about the current status of six months 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 31 July 2023.
   https://www.rfc-editor.org/info/rfc9416.

Copyright Notice

   Copyright (c) 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.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Issues with the Specification of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Common Flaws in the Generation of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Requirements for Transient Numeric Identifiers  . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Network

   Networking protocols employ a variety of transient numeric
   identifiers for different protocol entities, ranging from DNS Transaction IDs
   (TxIDs) to transport protocol numbers (e.g.  TCP ports) or objects, such as IPv4 and IPv6
   Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers (IIDs).
   (IIDs) [RFC4291], transport-protocol ephemeral port numbers
   [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC9293], NTP
   Reference IDs (REFIDs) [RFC5905], and DNS IDs [RFC1035].  These
   identifiers usually typically have specific properties requirements (e.g., uniqueness
   during a specified period of time) that must be satisfied such that
   they do not result in negative interoperability implications (e.g., uniqueness
   during a specified period of time), implications, and an
   associated failure severity when such properties requirements are not met.

   The TCP/IP protocol suite alone has met
   [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 IETF
   protocols have been subject to a variety of
   attacks on its transient numeric identifiers over the past 30 years
   or more, attacks, with effects
   ranging from Denial of Service (DoS) or data
   injection, injection to information leakage
   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 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 for of a given transient numeric
   identifier,
   there exists practical empirical evidence [I-D.irtf-pearg-numeric-ids-history] exists that doing so without
   negatively affecting the security and/or privacy properties of the
   aforementioned protocols is prone to error. error [RFC9414].

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

   *  Predictable TCP sequence numbers (see e.g.  [Morris1985],
      [Bellovin1989], and [RFC6528])

   *  Predictable transport protocol numbers (see e.g.  [Silbersack2005]
      and [RFC6056])

   *  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. (e.g., see [RFC7217], [RFC7707], and
      [RFC7721])
      [RFC7721]),

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

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

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

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

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

   We note that the use of cryptographic techniques for confidentiality
   and authentication might not eliminate all the issues associated with
   predictable transient numeric identifiers.  Therefore, due diligence
   in the specification of transient numeric identifiers is required
   even when cryptographic techniques are employed.

   Note:

      |  NOTE: For example, cryptographic authentication can readily
      |  mitigate data injection attacks even in the presence of
      |  predictable transient numeric identifiers (such as "sequence
      |  numbers").  However, use of flawed algorithms (such as global
      |  counters) for generating transient numeric identifiers could
      |  still result in information leakages even when cryptographic
      |  techniques are employed.  These information leakages could in
      |  turn be leveraged to perform other devastating attacks (please
      |  see
      [I-D.irtf-pearg-numeric-ids-generation] [RFC9415] for further details).

   Section 3 provides an overview of common flaws in the specification
   of transient numeric identifiers.  Section 4 provides an overview of
   common flaws in the implications generation of predictable transient numeric identifiers. identifiers and
   their associated security and privacy implications.  Finally,
   Section 5 provides key guidelines for protocol designers.

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.) 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.

   Failure Severity:
      The interoperability consequences of a failure to comply with the
      interoperability requirements of a given identifier.  Severity
      considers the worst potential consequence of a failure, determined
      by the system damage and/or time lost to repair the failure.  In
      this document document, we define two types of failure severity: "soft" and
      "hard".

   Hard

   Soft Failure:
      A hard failure recoverable condition in which a protocol does not operate in
      the prescribed manner but normal operation can be resumed
      automatically in a short period of time.  For example, a simple
      packet-loss event that is subsequently recovered with a
      retransmission can be considered a soft failure.

   Hard Failure:
      A non-recoverable condition in which a protocol does not operate
      in the prescribed manner or it operates with excessive degradation
      of service.  For example, an established TCP connection that is
      aborted due to an error condition constitutes, from the point of
      view of the transport protocol, a hard failure, since it enters a
      state from which normal operation cannot be recovered.

   Soft Failure:
      A soft failure is a recoverable condition in which a protocol does
      not operate in the prescribed manner but normal operation can be
      resumed automatically in a short period of time.  For example, a
      simple packet-loss event that is subsequently recovered with a
      retransmission can be considered a soft failure.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Issues with the Specification of Transient Numeric Identifiers

   A recent survey of

   Recent work on transient numeric identifier usage in protocol
   specifications and implementations
   [I-D.irtf-pearg-numeric-ids-history] [RFC9414] [RFC9415] revealed 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

   Both under-specifying under specifying and over-specifying over specifying transient numeric
   identifiers is hazardous.  TCP port numbers and sequence numbers [RFC0793] and local ports [RFC0793], as well as DNS TxID
   [RFC1035]
   IDs [RFC1035], were originally under-specified, under specified, leading to
   implementations that used resulted in predictable values and thus were
   vulnerable to numerous off-path attacks.  Over-specification,  Over specification, as for
   IPv6 Interface Identifiers (IIDs) [RFC4291] and Fragment IPv6 Identification
   values [RFC2460], left implementations unable to respond to security
   and privacy issues stemming from the mandated or recommended
   algorithms -- IPv6 IIDs need not expose privacy-sensitive link-layer
   addresses, and predictable IPv6 Fragment Identifiers Header Identification values
   invite the same off-path attacks that plague TCP.

   Finally, there are protocol implementations that simply fail to
   comply with existing protocol specifications.  That is, appropriate
   guidance is provided by the protocol specification (whether it be the
   core specification or an update to it), but an implementation simply
   fails to follow such guidance.  For example, some popular operating
   systems still fail to implement transport-protocol port
   randomization, as specified in [RFC6056].

   Clear specification of the interoperability requirements for the
   transient numeric identifiers will help identify possible algorithms
   that could be employed to generate them, them and also make evident if such
   identifiers are being over-specified. over specified.  A protocol specification will
   usually also benefit from a vulnerability assessment of the transient
   numeric identifiers they specify, specify to prevent the corresponding
   considerations from being overlooked.

4.  Common Flaws in the Generation of Transient Numeric Identifiers

   This section briefly notes common flaws associated with the
   generation of transient numeric identifiers.  Such common flaws
   include, but are not limited to:

   *  Employing  employing trivial algorithms (e.g. (e.g., global counters) that result
      in predictable identifiers identifiers,

   *  Employing  employing the same identifier across contexts in which constancy
      is not required required,

   *  Re-using  reusing identifiers across different protocols or layers of the
      protocol stack stack,

   *  Initializing  initializing counters or timers to constant values, values when such
      initialization is not required required,

   *  Employing  employing the same increment space across different contexts contexts, and

   *  Use  use of flawed pseudo-random number generators Pseudorandom Number Generators (PRNGs).

   Employing trivial algorithms for generating the identifiers means
   that any node that is able to sample such identifiers can easily
   predict future identifiers employed by the victim node.

   When one identifier is employed across contexts where such constancy
   is not needed, activity correlation is made possible.  For example,
   employing an identifier that is constant across networks allows for
   node tracking across networks.

   Re-using

   Reusing identifiers across different layers or protocols ties the
   security and privacy properties of the protocol re-using reusing the
   identifier to the security and privacy properties of the original
   identifier (over which the protocol re-using reusing the identifier may have
   no control regarding its generation).  Besides, when re-using reusing an
   identifier across protocols from different layers, the goal of
   isolating the properties of a layer from that those of another layer is
   broken, and the vulnerability assessment may be harder to perform, perform
   since the combined system, rather than each protocol in isolation isolation,
   will have to be assessed.

   At times, a protocol needs to convey order information (whether it be
   sequence, timing, etc.).  In many cases, there is no reason for the
   corresponding counter or timer to be initialized to any specific
   value e.g.
   value, e.g., at system bootstrap.  Similarly, there may not be a need
   for the difference between successive counted counter values to be a
   predictable.

   A node that implements a per-context linear function may share the
   increment space among different contexts (please see the "Simple
   Hash-Based PRF-
   Based Algorithm" section in [I-D.irtf-pearg-numeric-ids-generation]). [RFC9415]).  Sharing the same increment
   space allows an attacker that can sample identifiers in other context to e.g.
   to, e.g., learn how many identifiers have been generated between two
   sampled values.

   Finally, some implementations have been found to employ flawed PRNGs
   (see e.g.
   (e.g., see [Klein2007]).

5.  Requirements for Transient Numeric Identifiers

   Protocol specifications that employ transient numeric identifiers
   MUST explicitly specify the interoperability requirements for the
   aforementioned transient numeric identifiers (e.g., required
   properties such as uniqueness, along with the failure severity if
   such properties requirements are not met).

   A vulnerability assessment of the aforementioned transient numeric
   identifiers MUST be performed as part of the specification process.
   Such vulnerability assessment should cover, at least, spoofing,
   tampering, repudiation, information disclosure, denial of service, DoS, and elevation of
   privilege.

      Note: Section

      |  NOTE: Sections 8 and Section 9 of
      [I-D.irtf-pearg-numeric-ids-generation] [RFC9415] provide a general
      |  vulnerability assessment of transient numeric identifiers,
      |  along with a vulnerability assessment of common algorithms for
      |  generating transient numeric identifiers.  Please see
      |  [Shostack2014] for further guidance on threat modelling. modeling.

   Protocol specifications SHOULD NOT employ predictable transient
   numeric identifiers, except when such predictability is the result of
   their interoperability requirements.

   Protocol specifications that employ transient numeric identifiers
   SHOULD recommend an algorithm for generating the aforementioned
   transient numeric identifiers that mitigates the vulnerabilities
   identified in the previous step, such as those discussed in
   [I-D.irtf-pearg-numeric-ids-generation].
   [RFC9415].

   As discussed in Section 1, use of cryptographic techniques for
   confidentiality and authentication might not eliminate all the issues
   associated with predictable transient numeric identifiers.
   Therefore, the advice from this section MUST still be applied for
   cases where cryptographic techniques are employed for confidentiality or
   authentication of the associated transient numeric identifiers. are employed.

6.  IANA Considerations

   There are

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

7.  Security Considerations

   This entire document is about the security and privacy implications
   of transient numeric identifiers, identifiers and formally updates [RFC3552] such
   that the security and privacy implications of transient numeric
   identifiers are addressed when writing the "Security Considerations"
   section of future RFCs.

8.  Acknowledgements

   The authors would like to thank Bernard Aboba, Brian Carpenter, Roman
   Danyliw, Theo de Raadt, Lars Eggert, Russ Housley, Benjamin Kaduk,
   Charlie Kaufman, Erik Kline, Alvaro Retana, Joe Touch, Michael
   Tuexen, Robert Wilton, and Paul Wouters, 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, for providing valuable
   comments on [I-D.gont-predictable-numeric-ids] , on which the present
   document is based.

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

9.  References

9.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

9.2.  Informative References

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC7739]  Gont, F., "Security Implications

   [RFC8174]  Leiba, B., "Ambiguity of Predictable Fragment
              Identification Values", RFC 7739, DOI 10.17487/RFC7739,
              February 2016, <https://www.rfc-editor.org/info/rfc7739>.

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

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

   [RFC6528]  Gont, F. and S. Bellovin, "Defending against Sequence
              Number Attacks",
              2119 Key Words", BCP 14, RFC 6528, 8174, DOI 10.17487/RFC6528, February
              2012, <https://www.rfc-editor.org/info/rfc6528>. 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [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>.

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

   [Klein2007]
              Klein, A., "OpenBSD DNS Cache Poisoning and 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>.

   [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>.

   [PREDICTABLE-NUMERIC-IDS]
              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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
              Protocol Port Randomization", BCP 156, RFC 6056,
              DOI 10.17487/RFC6056, January 2011,
              <https://www.rfc-editor.org/info/rfc6056>.

   [Silbersack2005]
              Silbersack, M.J., "Improving TCP/IP security through
              randomization without sacrificing interoperability",
              EuroBSDCon 2005 Conference, 2005,
              <http://www.silby.com/eurobsdcon05/
              eurobsdcon_silbersack.pdff>.

   [I-D.gont-predictable-numeric-ids]

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

   [RFC6528]  Gont, F. and 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 Employed in Network Protocols",
              Work in Progress, Internet-Draft, draft-gont-predictable-
              numeric-ids-03, 11 March 2019,
              <https://www.ietf.org/archive/id/draft-gont-predictable-
              numeric-ids-03.txt>. with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [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>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and
              specification", STD 13, R.
              Scheffenegger, Ed., "TCP Extensions for High Performance",
              RFC 1035, 7323, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC4291]  Hinden, R. 10.17487/RFC7323, September 2014,
              <https://www.rfc-editor.org/info/rfc7323>.

   [RFC7707]  Gont, F. and S. Deering, "IP Version 6 Addressing
              Architecture", T. Chown, "Network Reconnaissance in IPv6
              Networks", RFC 4291, 7707, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [Klein2007]
              Klein, 10.17487/RFC7707, March 2016,
              <https://www.rfc-editor.org/info/rfc7707>.

   [RFC7721]  Cooper, A., "OpenBSD DNS Cache Poisoning Gont, F., 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>.

   [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>.

   [Shostack2014]
              Shostack, A., "Threat Modeling: Designing D. Thaler, "Security and Privacy
              Considerations for Security",
              Wiley, 1st edition, 2014.

   [I-D.irtf-pearg-numeric-ids-history] 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>.

   [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>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

   [RFC9414]  Gont, F. and I. Arce, "Unfortunate History of Transient
              Numeric Identifiers", Work in Progress, Internet-Draft,
              draft-irtf-pearg-numeric-ids-history-11, 11 December 2022,
              <https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-
              ids-history-11.txt>.

   [I-D.irtf-pearg-numeric-ids-generation] RFC 9414, DOI 10.17487/RFC9414, July
              2023, <https://www.rfc-editor.org/info/rfc9414>.

   [RFC9415]  Gont, F. and I. Arce, "On the Generation of Transient
              Numeric Identifiers", Work in Progress, Internet-Draft,
              draft-irtf-pearg-numeric-ids-generation-12, 11 RFC 9415, DOI 10.17487/RFC9415, July
              2023, <https://www.rfc-editor.org/info/rfc941v>.

   [Sanfilippo1998a]
              Sanfilippo, S., "about the ip header id", message to the
              Bugtraq mailing list, December
              2022, <https://www.ietf.org/archive/id/draft-irtf-pearg-
              numeric-ids-generation-12.txt>.

   [IANA-PROT]
              IANA, "Protocol Registries",
              <https://www.iana.org/protocols>. 1998,
              <https://seclists.org/bugtraq/1998/Dec/48>.

   [Schuba1993]
              Schuba, C., "Addressing Weakness in the Domain Name System
              Protocol", August 1993,
              <http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/
              schuba-DNS-msthesis.pdf>.

   [Shostack2014]
              Shostack, A., "Threat Modeling: Designing for Security",
              Wiley, 1st edition, February 2014.

   [Silbersack2005]
              Silbersack, M., "Improving TCP/IP security through
              randomization without sacrificing interoperability",
              EuroBSDCon 2005 Conference, January 2005,
              <http://www.silby.com/eurobsdcon05/
              eurobsdcon_silbersack.pdf>.

   [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>.

Acknowledgements

   The authors would like to thank (in alphabetical order) Bernard
   Aboba, Brian Carpenter, Roman Danyliw, Theo de Raadt, Lars Eggert,
   Russ Housley, Benjamin Kaduk, Charlie Kaufman, Erik Kline, Alvaro
   Retana, Joe Touch, Michael Tüxen, Robert Wilton, and Paul Wouters for
   providing valuable comments on draft versions of this document.

   The authors would like to thank (in alphabetical order) Steven
   Bellovin, Joseph Lorenzo Hall, and Gre Norcie for providing valuable
   comments on [PREDICTABLE-NUMERIC-IDS], on which the present document
   is based.

   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