<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IRTF" category="info" consensus="true" docName="draft-irtf-pearg-numeric-ids-generation-12" number="9415" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" prepTime="2023-07-21T17:15:53" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-generation-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9415" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Generation of Transient Numeric IDs">On the Generation of Transient Numeric Identifiers</title>
    <seriesInfo name="RFC" value="9415" stream="IRTF"/>
    <author fullname="Fernando Gont" initials="F." surname="Gont">
      <organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</organization>
      <address>
        <postal>
          <street>Segurola y Habana 4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <country>Argentina</country>
        </postal>
        <email>fgont@si6networks.com</email>
        <uri>https://www.si6networks.com</uri>
      </address>
    </author>
    <author fullname="Ivan Arce" initials="I." surname="Arce">
      <organization abbrev="Quarkslab" showOnFrontPage="true">Quarkslab</organization>
      <address>
        <postal>
          <street>Segurola y Habana 4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <country>Argentina</country>
        </postal>
        <email>iarce@quarkslab.com</email>
        <uri>https://www.quarkslab.com</uri>
      </address>
    </author>
    <date month="07" year="2023"/>
    <workgroup>Privacy Enhancements and Assessments</workgroup>
    <keyword>security</keyword>
    <keyword>vulnerability</keyword>
    <keyword>algorithm</keyword>
    <keyword>attack</keyword>
    <keyword>fingerprinting</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties. This document is a product of the Privacy Enhancements and Assessments Research Group (PEARG) in the IRTF.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and 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 Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not
            candidates for any level of Internet Standard; see Section 2 of RFC
            7841.   
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9415" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-model">Threat Model</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issues-with-the-specificati">Issues with the Specification of Transient Numeric Identifiers</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-failure-severity">Protocol Failure Severity</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-categorizing-transient-nume">Categorizing Transient Numeric Identifiers</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-common-algorithms-for-trans">Common Algorithms for Transient Numeric Identifier Generation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-1-uniqueness-soft-">Category #1: Uniqueness (Soft Failure)</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-2-uniqueness-hard-">Category #2: Uniqueness (Hard Failure)</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-3-uniqueness-stabl">Category #3: Uniqueness, Stable within Context (Soft Failure)</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-4-uniqueness-monot">Category #4: Uniqueness, Monotonically Increasing within Context (Hard Failure)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-common-vulnerabilities-asso">Common Vulnerabilities Associated with Transient Numeric Identifiers</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-activity-correlatio">Network Activity Correlation</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-leakage">Information Leakage</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fingerprinting">Fingerprinting</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-exploitation-of-the-semanti">Exploitation of the Semantics of Transient Numeric Identifiers</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-exploitation-of-collisions-">Exploitation of Collisions of Transient Numeric Identifiers</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.6">
                <t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-exploitation-of-predictable">Exploitation of Predictable Transient Numeric Identifiers for Injection Attacks</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.7">
                <t indent="0" pn="section-toc.1-1.8.2.7.1"><xref derivedContent="8.7" format="counter" sectionFormat="of" target="section-8.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cryptanalysis">Cryptanalysis</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vulnerability-assessment-of">Vulnerability Assessment of Transient Numeric Identifiers</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-1-uniqueness-soft-f">Category #1: Uniqueness (Soft Failure)</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-2-uniqueness-hard-f">Category #2: Uniqueness (Hard Failure)</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-3-uniqueness-stable">Category #3: Uniqueness, Stable within Context (Soft Failure)</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-category-4-uniqueness-monoto">Category #4: Uniqueness, Monotonically Increasing within Context (Hard Failure)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-algorithms-and-techniques-w">Algorithms and Techniques with Known Issues</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-predictable-linear-identifi">Predictable Linear Identifiers Algorithm</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-random-increments-algorithm">Random-Increments Algorithm</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.3">
                <t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reusing-identifiers-across-">Reusing Identifiers Across Different Contexts</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Identification values <xref target="RFC0791" format="default" sectionFormat="of" derivedContent="RFC0791"/> <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, IPv6 Interface Identifiers (IIDs) <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/>, transport-protocol ephemeral port numbers <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>, TCP Initial Sequence Numbers (ISNs) <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>, NTP Reference IDs (REFIDs) <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/>, and DNS IDs <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>. These identifiers typically have specific requirements (e.g., uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications and an associated failure severity when such requirements are not met.</t>
      <aside pn="section-1-2">
        <t indent="0" pn="section-1-2.1">NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".</t>
      </aside>
      <t indent="0" pn="section-1-3">For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring <xref target="RFC7258" format="default" sectionFormat="of" derivedContent="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 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 <xref target="RFC9414" format="default" sectionFormat="of" derivedContent="RFC9414"/>.</t>
      <t indent="0" pn="section-1-4">For example, implementations have been subject to security and/or privacy issues resulting from:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-5">
        <li pn="section-1-5.1">predictable IPv4 or IPv6 Identification values (e.g., see <xref target="Sanfilippo1998a" format="default" sectionFormat="of" derivedContent="Sanfilippo1998a"/>, <xref target="RFC6274" format="default" sectionFormat="of" derivedContent="RFC6274"/>, and <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/>),</li>
        <li pn="section-1-5.2">predictable IPv6 IIDs (e.g., see <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/>, <xref target="RFC7707" format="default" sectionFormat="of" derivedContent="RFC7707"/>, and <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/>),</li>
        <li pn="section-1-5.3">predictable transport-protocol ephemeral port numbers (e.g., see <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/> and <xref target="Silbersack2005" format="default" sectionFormat="of" derivedContent="Silbersack2005"/>),</li>
        <li pn="section-1-5.4">predictable TCP Initial Sequence Numbers (ISNs) (e.g., see <xref target="Morris1985" format="default" sectionFormat="of" derivedContent="Morris1985"/>, <xref target="Bellovin1989" format="default" sectionFormat="of" derivedContent="Bellovin1989"/>, and <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/>),</li>
        <li pn="section-1-5.5">predictable initial timestamps in TCP timestamps options (e.g., see <xref target="TCPT-uptime" format="default" sectionFormat="of" derivedContent="TCPT-uptime"/> and <xref target="RFC7323" format="default" sectionFormat="of" derivedContent="RFC7323"/>), and</li>
        <li pn="section-1-5.6">predictable DNS IDs (see, e.g., <xref target="Schuba1993" format="default" sectionFormat="of" derivedContent="Schuba1993"/> and <xref target="Klein2007" format="default" sectionFormat="of" derivedContent="Klein2007"/>).</li>
      </ul>
      <t indent="0" pn="section-1-6">

Recent history indicates 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, and inappropriate algorithms to generate such identifiers are either suggested in the specifications or selected by implementers. As a result, advice in this area is warranted.
</t>
      <t indent="0" pn="section-1-7">We note that the use of cryptographic techniques may readily mitigate some of the issues arising from predictable transient numeric identifiers. 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.
</t>
      <t indent="0" pn="section-1-8">This document contains a non-exhaustive survey of transient numeric identifiers employed in various IETF protocols and aims to categorize such identifiers based on their interoperability requirements and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each category while minimizing negative security and privacy implications. Finally, it analyzes several algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties.
</t>
      <t indent="0" pn="section-1-9">This document represents the consensus of the Privacy Enhancements and Assessments Research Group (PEARG).</t>
    </section>
    <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <dl newline="true" spacing="normal" indent="3" pn="section-2-1">
        <dt pn="section-2-1.1">Transient Numeric Identifier:</dt>
        <dd pn="section-2-1.2">A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, 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 and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically assigned numeric identifiers (see, e.g., <xref target="IANA-PROT" format="default" sectionFormat="of" derivedContent="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.
</dd>
        <dt pn="section-2-1.3">Failure Severity:</dt>
        <dd pn="section-2-1.4">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, we define two types of failure severity: "soft failure" and "hard failure".
</dd>
        <dt pn="section-2-1.5">Soft Failure:</dt>
        <dd pn="section-2-1.6">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 packet retransmission can be considered a soft failure.
</dd>
        <dt pn="section-2-1.7">Hard Failure:</dt>
        <dd pn="section-2-1.8">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 resumed.
</dd>
      </dl>
    </section>
    <section anchor="threat-model" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-threat-model">Threat Model</name>
      <t indent="0" pn="section-3-1">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 and that the attacker can only observe traffic explicitly directed to the attacker. Similarly, an attacker cannot observe traffic transferred between the sender and the receiver(s) of a target protocol but may be able to interact with any of these entities, including by, e.g., sending any traffic to them to sample transient numeric identifiers employed by the target hosts when communicating with the attacker.
</t>
      <t indent="0" pn="section-3-2">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., sample the TCP ISNs employed by these hosts when communicating with the attacker.</t>
      <t indent="0" pn="section-3-3">Similarly, when considering host-tracking attacks based on IPv6 Interface Identifiers, we consider an attacker may learn the IPv6 address employed by a victim host if, e.g., the address becomes exposed as a result of the victim host communicating with an 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 originally learned by the attacker.
      Alternatively, an attacker may perform host-tracking if, e.g., the victim host communicates with an attacker-operated server as it moves from one location to another, thereby exposing its configured addresses. We note that none of these scenarios require the attacker observe traffic not explicitly directed to the attacker.
</t>
    </section>
    <section anchor="issues" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-issues-with-the-specificati">Issues with the Specification of Transient Numeric Identifiers</name>
      <t indent="0" pn="section-4-1">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:

</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">protocol specifications that under specify their transient numeric identifiers</li>
        <li pn="section-4-2.2">protocol specifications that over specify their transient numeric identifiers</li>
        <li pn="section-4-2.3">protocol implementations that simply fail to comply with the specified requirements</li>
      </ul>
      <t indent="0" pn="section-4-3">A number of IETF protocol specifications under specified their transient numeric identifiers, thus leading to implementations that were vulnerable to numerous off-path
   attacks. Examples of them are the specification of TCP local ports in <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> or the specification of the DNS ID in <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>.</t>
      <aside pn="section-4-4">
        <t indent="0" pn="section-4-4.1">NOTE: The TCP local port in an active OPEN request is commonly known as the "ephemeral port" of the corresponding TCP connection <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>.</t>
      </aside>
      <t indent="0" pn="section-4-5">On the other hand, there are a number of IETF protocol specifications that over specify some of their associated transient numeric identifiers. For example, <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/>. Similarly, <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> suggests the use of a global counter for the generation of Identification values when the interoperability requirement of uniqueness per {IPv6 Source Address, IPv6 Destination Address} could be achieved with other algorithms that do not result in negative security and privacy implications <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/>.</t>
      <t indent="0" pn="section-4-6">Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. For example, some popular operating systems still fail to implement transport-protocol ephemeral port randomization, as recommended in <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>, or TCP Initial Sequence Number randomization, as recommended in <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>.</t>
    </section>
    <section anchor="failure-severity" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-protocol-failure-severity">Protocol Failure Severity</name>
      <t indent="0" pn="section-5-1"><xref target="terminology" format="default" sectionFormat="of" derivedContent="Section 2"/> defines the concept of "failure severity", along with two types of failure severities that we employ throughout this document: soft and hard.</t>
      <t indent="0" pn="section-5-2">Our analysis of the severity of a failure is performed from the point of view of the protocol in question. However, the corresponding severity on the upper protocol (or application) might not be the same as that of the protocol in question. For example, a TCP connection that is aborted might or might not result in a hard failure of the upper application, i.e., if the upper application can establish a new TCP connection without any impact on the application, a hard failure at the TCP protocol may have no severity at the application layer. On the other hand, if a hard failure of a TCP connection results in excessive degradation of service at the application layer, it will also result in a hard failure at the application.
</t>
    </section>
    <section anchor="categorizing" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-categorizing-transient-nume">Categorizing Transient Numeric Identifiers</name>
      <t indent="0" pn="section-6-1">This section includes a non-exhaustive survey of transient numeric identifiers, which are representative of all the possible combinations of interoperability requirements and failure severities found in popular protocols of different layers. Additionally, it proposes a number of categories that can accommodate these identifiers based on their interoperability requirements and their associated failure severity (soft or hard).
      </t>
      <aside pn="section-6-2">
        <t indent="0" pn="section-6-2.1">NOTE: All other transient numeric identifiers that were analyzed as part of this effort could be accommodated into one of the existing categories from <xref target="survey-table" format="default" sectionFormat="of" derivedContent="Table 1"/>.
</t>
      </aside>
      <table anchor="survey-table" align="center" pn="table-1">
        <name slugifiedName="name-survey-of-transient-numeric">Survey of Transient Numeric Identifiers</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">Identifier</th>
            <th align="center" colspan="1" rowspan="1">Interoperability Requirements</th>
            <th align="center" colspan="1" rowspan="1">Failure Severity</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">IPv6 ID</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness (for IPv6 address pair)</td>
            <td align="center" colspan="1" rowspan="1">Soft/Hard (1)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">IPv6 IID</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness (and stable within IPv6 prefix) (2)</td>
            <td align="center" colspan="1" rowspan="1">Soft (3)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">TCP ISN</td>
            <td align="center" colspan="1" rowspan="1">Monotonically increasing (4)</td>
            <td align="center" colspan="1" rowspan="1">Hard (4)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">TCP initial timestamp</td>
            <td align="center" colspan="1" rowspan="1">Monotonically increasing (5)</td>
            <td align="center" colspan="1" rowspan="1">Hard (5)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">TCP ephemeral port</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness (for connection ID)</td>
            <td align="center" colspan="1" rowspan="1">Hard</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">IPv6 Flow Label</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness</td>
            <td align="center" colspan="1" rowspan="1">None (6)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">DNS ID</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness</td>
            <td align="center" colspan="1" rowspan="1">None (7)</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-6-4">NOTE:</t>
      <ol type="(%d)" spacing="normal" indent="adaptive" start="1" pn="section-6-5">
        <li pn="section-6-5.1" derivedCounter="(1)">While a single collision of IPv6 Identification (ID) values would simply lead to a single packet drop (and hence, a "soft" failure), repeated collisions at high data rates might result in self-propagating collisions of IPv6 IDs, thus possibly leading to a hard failure <xref target="RFC4963" format="default" sectionFormat="of" derivedContent="RFC4963"/>.</li>
        <li pn="section-6-5.2" derivedCounter="(2)">While the interoperability requirements are simply that the Interface Identifier results in a unique IPv6 address, for operational reasons, it is typically desirable that the resulting IPv6 address (and hence, the corresponding Interface Identifier) be stable within each network <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> <xref target="RFC8064" format="default" sectionFormat="of" derivedContent="RFC8064"/>.</li>
        <li pn="section-6-5.3" derivedCounter="(3)">While IPv6 Interface Identifiers must result in unique IPv6 addresses, IPv6 Duplicate Address Detection (DAD) <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/> allows for the detection of duplicate addresses, and hence, such Interface Identifier collisions can be recovered.</li>
        <li pn="section-6-5.4" derivedCounter="(4)">In theory, there are no interoperability requirements for TCP Initial Sequence Numbers (ISNs), since the TIME-WAIT state and TCP's "quiet time" concept take care of old segments from previous incarnations of a connection. However, a widespread optimization allows for a new incarnation of a previous connection to be created if the ISN of the incoming SYN is larger than the last sequence number seen in that direction for the previous incarnation of the connection. Thus, monotonically increasing TCP ISNs allow for such optimization to work as expected <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/> and can help avoid connection-establishment failures.</li>
        <li pn="section-6-5.5" derivedCounter="(5)">Strictly speaking, there are no interoperability requirements for the <strong>initial</strong> TCP timestamp employed by a TCP instance (i.e., the TS Value (TSval) in a segment with the SYN bit set). However, some TCP implementations allow a new incarnation of a previous connection to be created if the TSval of the incoming SYN is larger than the last TSval seen in that direction for the previous incarnation of the connection (please see <xref target="RFC6191" format="default" sectionFormat="of" derivedContent="RFC6191"/>). Thus, monotonically increasing TCP initial timestamps (across connections to the same endpoint) allow for such optimization to work as expected <xref target="RFC6191" format="default" sectionFormat="of" derivedContent="RFC6191"/> and can help avoid connection-establishment failures.</li>
        <li pn="section-6-5.6" derivedCounter="(6)">The IPv6 Flow Label <xref target="RFC6437" format="default" sectionFormat="of" derivedContent="RFC6437"/>, along with the IPv6 Source Address and the IPv6 Destination Address, is typically employed for load sharing <xref target="RFC7098" format="default" sectionFormat="of" derivedContent="RFC7098"/>.
Reuse of a Flow Label value for the same set {Source Address, Destination Address} would typically cause both flows to be multiplexed onto the same link. However, as long as this does not occur deterministically, it will not result in any negative implications.</li>
        <li pn="section-6-5.7" derivedCounter="(7)">DNS IDs are employed, together with the IP Source Address, the IP Destination Address, the transport-protocol Source Port, and the transport-protocol Destination Port, to match DNS requests and responses. However, since an implementation knows which DNS requests were sent for that set of {IP Source Address, IP Destination Address, transport-protocol Source Port, transport-protocol Destination Port, DNS ID}, a collision of DNS IDs would result, if anything, in a small performance penalty (the response would nevertheless be discarded when it is found that it does not answer the query sent in the corresponding DNS query).</li>
      </ol>
      <t indent="0" pn="section-6-6">Based on the survey above, we can categorize identifiers as follows:</t>
      <table anchor="cat-table" align="center" pn="table-2">
        <name slugifiedName="name-identifier-categories">Identifier Categories</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">Cat #</th>
            <th align="center" colspan="1" rowspan="1">Category</th>
            <th align="center" colspan="1" rowspan="1">Sample Numeric IDs</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">1</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness (soft failure)</td>
            <td align="center" colspan="1" rowspan="1">IPv6 Flow L., DNS ID</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">2</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness (hard failure)</td>
            <td align="center" colspan="1" rowspan="1">IPv6 ID, TCP ephemeral port</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">3</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness, stable within context (soft failure)</td>
            <td align="center" colspan="1" rowspan="1">IPv6 IID</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">4</td>
            <td align="center" colspan="1" rowspan="1">Uniqueness, monotonically increasing within context (hard failure)</td>
            <td align="center" colspan="1" rowspan="1">TCP ISN, TCP initial timestamp</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-6-8">
We note that Category #4 could be considered a generalized case of Category #3, in which a monotonically increasing element is added to a stable (within context) element, such that the resulting identifiers are monotonically increasing within a specified context. That is, the same algorithm could be employed for both #3 and #4, given appropriate parameters.
</t>
    </section>
    <section anchor="common-algorithms" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-common-algorithms-for-trans">Common Algorithms for Transient Numeric Identifier Generation</name>
      <t indent="0" pn="section-7-1">The following subsections describe some sample algorithms that can be employed for generating transient numeric identifiers for each of the categories above while mitigating the vulnerabilities analyzed in <xref target="vulns" format="default" sectionFormat="of" derivedContent="Section 8"/> of this document.</t>
      <t indent="0" pn="section-7-2">All of the variables employed in the algorithms of the following subsections are of "unsigned integer" type, except for the "retry" variable, which is of (signed) "integer" type.</t>
      <section anchor="cat-1-alg" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-category-1-uniqueness-soft-">Category #1: Uniqueness (Soft Failure)</name>
        <t indent="0" pn="section-7.1-1">The requirement of uniqueness with a soft failure severity can be complied with a Pseudorandom Number Generator (PRNG).
</t>
        <aside pn="section-7.1-2">
          <t indent="0" pn="section-7.1-2.1">NOTE: Please see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> regarding randomness requirements for security.</t>
        </aside>
        <t indent="0" pn="section-7.1-3">While most systems provide access to a PRNG, many of such PRNG implementations are not cryptographically secure and therefore might be statistically biased or subject to adversarial influence. For example, ISO C <xref target="C11" format="default" sectionFormat="of" derivedContent="C11"/> rand(3) implementations are not cryptographically secure.
</t>
        <aside pn="section-7.1-4">
          <t indent="0" pn="section-7.1-4.1">NOTE: Section 7.1 ("Uniform Deviates") of <xref target="Press1992" format="default" sectionFormat="of" derivedContent="Press1992"/> discusses the underlying issues affecting ISO C <xref target="C11" format="default" sectionFormat="of" derivedContent="C11"/> rand(3) implementations.
          </t>
        </aside>
        <t indent="0" pn="section-7.1-5">On the other hand, a number of systems provide an interface to a Cryptographically Secure PRNG (CSPRNG) <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> <xref target="RFC8937" format="default" sectionFormat="of" derivedContent="RFC8937"/>, which guarantees high entropy, unpredictability, and good statistical distribution of the random values generated.  For example, GNU/Linux's CSPRNG implementation is available via the getentropy(3) interface <xref target="GETENTROPY" format="default" sectionFormat="of" derivedContent="GETENTROPY"/>, while OpenBSD's CSPRNG implementation is available via the arc4random(3) and arc4random_uniform(3) interfaces <xref target="ARC4RANDOM" format="default" sectionFormat="of" derivedContent="ARC4RANDOM"/>. Where available, these CSPRNGs should be preferred over, e.g., POSIX <xref target="POSIX" format="default" sectionFormat="of" derivedContent="POSIX"/> random(3) or ISO C <xref target="C11" format="default" sectionFormat="of" derivedContent="C11"/> rand(3) implementations.</t>
        <t indent="0" pn="section-7.1-6">In scenarios where a CSPRNG is not readily available to select transient numeric identifiers of Category #1, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision.

</t>
        <aside pn="section-7.1-7">
          <t indent="0" pn="section-7.1-7.1">NOTE: <xref target="Aumasson2018" format="default" sectionFormat="of" derivedContent="Aumasson2018"/>, <xref target="Press1992" format="default" sectionFormat="of" derivedContent="Press1992"/>, and <xref target="Knuth1983" format="default" sectionFormat="of" derivedContent="Knuth1983"/> discuss theoretical and practical aspects of pseudorandom number generation and provide guidance on how to evaluate PRNGs.</t>
        </aside>
        <t indent="0" pn="section-7.1-8">We note that, since the premise is that collisions of transient numeric identifiers of this category only lead to soft failures, in many cases, the algorithm might not need to check the suitability of a selected identifier (i.e., the suitable_id() function, described below, could always return "true").</t>
        <t indent="0" pn="section-7.1-9">In scenarios where, e.g., simultaneous use of a given numeric identifier is undesirable and an implementation detects such condition, the implementation may opt to select the next available identifier in the same sequence or select another random number. <xref target="simple-randomization" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/> is an implementation of the former strategy, while <xref target="simple-randomization2" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/> is an implementation of the latter. Typically, the algorithm in <xref target="simple-randomization2" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/> results in a more uniform distribution of the generated transient numeric identifiers. However, for transient numeric identifiers where an implementation typically keeps local state about unsuitable/used identifiers, the algorithm in <xref target="simple-randomization2" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/> may require many more iterations than the algorithm in <xref target="simple-randomization" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/> to generate a suitable transient numeric identifier. This will usually be affected by the current usage ratio of transient numeric identifiers (i.e., the number of numeric identifiers considered suitable / total number of numeric identifiers) and other parameters. Therefore, in such cases, many implementations tend to prefer the algorithm in <xref target="simple-randomization" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/> over the algorithm in <xref target="simple-randomization2" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/>.
</t>
        <section anchor="simple-randomization" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-simple-randomization-algori">Simple Randomization Algorithm</name>
          <sourcecode type="c" markers="false" pn="section-7.1.1-1">
    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    next_id = min_id + (random() % id_range);
    retry = id_range;

    do {
        if (suitable_id(next_id)) {
            return next_id;
        }

        if (next_id == max_id) {
            next_id = min_id;
        } else {
            next_id++;
        }

        retry--;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
          <t indent="0" pn="section-7.1.1-2">NOTE:</t>
          <t indent="3" pn="section-7.1.1-3">random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique <xref target="Romailler2020" format="default" sectionFormat="of" derivedContent="Romailler2020"/> can be used.</t>
          <t indent="3" pn="section-7.1.1-4">suitable_id() is a function that checks, if possible and desirable, whether a candidate numeric identifier is suitable (e.g., whether it is in use or has been recently employed). Depending on how/where the numeric identifier is used, it may or may not be possible (or even desirable) to check whether the numeric identifier is suitable.
</t>
          <t indent="3" pn="section-7.1.1-5">All the variables (in this algorithm and all the others algorithms discussed in this document) are unsigned integers.</t>
          <t indent="0" pn="section-7.1.1-6">When an identifier is found to be unsuitable, this algorithm selects the next available numeric identifier in sequence. Thus, even when this algorithm selects numeric identifiers randomly, it is biased towards the first available numeric identifier after a sequence of unavailable numeric identifiers. For example, if this algorithm is employed for transport-protocol ephemeral port randomization <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/> and the local list of unsuitable port numbers (e.g., registered port numbers that should not be used for ephemeral ports) is significant, an attacker may actually have a significantly better chance of guessing an ephemeral port number.
</t>
          <t indent="0" pn="section-7.1.1-7">Assuming the randomness requirements for the PRNG are met (see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>), this algorithm does not suffer from any of the issues discussed in <xref target="vulns" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
        </section>
        <section anchor="simple-randomization2" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.1.2">
          <name slugifiedName="name-another-simple-randomizatio">Another Simple Randomization Algorithm</name>
          <t indent="0" pn="section-7.1.2-1">The following pseudocode illustrates another algorithm for selecting a random transient numeric identifier where, in the event a selected identifier is found to be unsuitable (e.g., already in use), another identifier is randomly selected:</t>
          <sourcecode type="c" markers="false" pn="section-7.1.2-2">
    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;

    do {
        next_id = min_id + (random() % id_range);

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry--;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
          <t indent="0" pn="section-7.1.2-3">NOTE:</t>
          <t indent="3" pn="section-7.1.2-4">random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique <xref target="Romailler2020" format="default" sectionFormat="of" derivedContent="Romailler2020"/> can be used.</t>
          <t indent="3" pn="section-7.1.2-5">suitable_id() is a function that checks, if possible and desirable, whether a candidate numeric identifier is suitable (e.g., if it is not already in use). Depending on how/where the numeric identifier is used, it may or may not be possible (or even desirable) to check whether the numeric identifier is in use (or whether it has been recently employed).
</t>
          <t indent="0" pn="section-7.1.2-6">When an identifier is found to be unsuitable, this algorithm selects another random numeric identifier. Thus, this algorithm might be unable to select a transient numeric identifier (i.e., return "ERROR"), even if there are suitable identifiers available, in cases where a large number of identifiers are found to be unsuitable (e.g., "in use").</t>
          <t indent="0" pn="section-7.1.2-7">Assuming the randomness requirements for the PRNG are met (see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>), this algorithm does not suffer from any of the issues discussed in <xref target="vulns" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
        </section>
      </section>
      <section anchor="cat-2-alg" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-category-2-uniqueness-hard-">Category #2: Uniqueness (Hard Failure)</name>
        <t indent="0" pn="section-7.2-1">One of the most trivial approaches for generating a unique transient numeric identifier (with a hard failure severity) is to reduce the identifier reuse frequency by generating the numeric identifiers with a monotonically increasing function (e.g., linear). As a result, any of the algorithms described in <xref target="cat-4-alg" format="default" sectionFormat="of" derivedContent="Section 7.4"/> ("Category #4: Uniqueness, Monotonically Increasing within Context (Hard Failure)") can be readily employed for complying with the requirements of this transient numeric identifier category.
</t>
        <t indent="0" pn="section-7.2-2">In cases where suitability (e.g., uniqueness) of the selected identifiers can be definitely assessed by the local system, any of the algorithms described in <xref target="cat-1-alg" format="default" sectionFormat="of" derivedContent="Section 7.1"/> ("Category #1: Uniqueness (Soft Failure)") can be readily employed for complying with the requirements of this numeric identifier category.</t>
        <aside pn="section-7.2-3">
          <t indent="0" pn="section-7.2-3.1">NOTE: In the case of, e.g., TCP ephemeral ports or TCP ISNs, a transient numeric identifier that might seem suitable from the perspective of the local system might actually be unsuitable from the perspective of the remote system (e.g., because there is state associated with the selected identifier at the remote system). Therefore, in such cases, it is not possible to employ the algorithms from <xref target="cat-1-alg" format="default" sectionFormat="of" derivedContent="Section 7.1"/> ("Category #1: Uniqueness (Soft Failure)").
</t>
        </aside>
      </section>
      <section anchor="cat-3-alg" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-category-3-uniqueness-stabl">Category #3: Uniqueness, Stable within Context (Soft Failure)</name>
        <t indent="0" pn="section-7.3-1">The goal of the following algorithm is to produce identifiers that are stable for a given context (identified by "CONTEXT") but that change when the aforementioned context changes. 
</t>
        <t indent="0" pn="section-7.3-2">In order to avoid storing the transient numeric identifiers computed for each CONTEXT in memory, the following algorithm employs a calculated technique (as opposed to keeping state in memory) to generate a stable transient numeric identifier for each given context.
</t>
        <sourcecode type="c" markers="false" pn="section-7.3-3">
    /* Transient Numeric ID selection function  */

    id_range = max_id - min_id + 1;

    retry = 0;

    do {
        offset = F(CONTEXT, retry, secret_key);
        next_id = min_id + (offset % id_range);

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry++;

    } while (retry &lt;= MAX_RETRIES);

    return ERROR;
</sourcecode>
        <t indent="0" pn="section-7.3-4">NOTE:</t>
        <t indent="3" pn="section-7.3-5">CONTEXT is the concatenation of all the elements that define a given context.</t>
        <t indent="3" pn="section-7.3-6">F() is a pseudorandom function (PRF). It must not be computable from the outside (without knowledge of the secret key). F() must also be difficult to reverse, such that it resists attempts to obtain the secret key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() should produce an output of at least as many bits as required for the transient numeric identifier. SipHash-2-4 (128-bit key, 64-bit output) <xref target="SipHash" format="default" sectionFormat="of" derivedContent="SipHash"/> and BLAKE3 (256-bit key, arbitrary-length output) <xref target="BLAKE3" format="default" sectionFormat="of" derivedContent="BLAKE3"/> are two possible options for F(). Alternatively, F() could be implemented with a keyed hash message authentication code (HMAC) <xref target="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/>. HMAC-SHA-256 <xref target="FIPS-SHS" format="default" sectionFormat="of" derivedContent="FIPS-SHS"/> would be one possible option for such implementation alternative. Note: Use of HMAC-MD5 <xref target="RFC1321" format="default" sectionFormat="of" derivedContent="RFC1321"/> or HMAC-SHA1 <xref target="FIPS-SHS" format="default" sectionFormat="of" derivedContent="FIPS-SHS"/> are not recommended for F() <xref target="RFC6151" format="default" sectionFormat="of" derivedContent="RFC6151"/> <xref target="RFC6194" format="default" sectionFormat="of" derivedContent="RFC6194"/>. The result of F() is no more secure than the secret key, and therefore, "secret_key" must be unknown to the attacker and must be of a reasonable length. "secret_key" must remain stable for a given CONTEXT, since otherwise, the numeric identifiers generated by this algorithm would not have the desired stability properties (i.e., stable for a given CONTEXT). In most cases, "secret_key" should be selected with a PRNG (see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for recommendations on choosing secrets) at an appropriate time and stored in stable or volatile storage (as necessary) for future use.
        </t>
        <t indent="3" pn="section-7.3-7">suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties. </t>
        <t indent="0" pn="section-7.3-8">In this algorithm, the function F() provides a stateless and stable per-CONTEXT offset, where CONTEXT is the concatenation of all the elements that define the given context. 
</t>
        <t indent="0" pn="section-7.3-9">For example, if this algorithm is expected to produce IPv6 IIDs that are unique per network interface and Stateless Address Autoconfiguration (SLAAC) prefix, CONTEXT should be the concatenation of, e.g., the network interface index and the SLAAC autoconfiguration prefix (please see <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> for an implementation of this algorithm for generation of stable IPv6 addresses).
</t>
        <t indent="0" pn="section-7.3-10">The result of F() is stored in the variable "offset", which may take any value within the storage type range, since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in <xref target="simple-randomization" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/>.</t>
        <t indent="0" pn="section-7.3-11">As noted above, suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties. Collisions (i.e., an identifier that is not unique) are recovered by incrementing the "retry" variable and recomputing F(), up to a maximum of MAX_RETRIES times. However, recovering from collisions will usually result in identifiers that fail to remain constant for the specified context. This is normally acceptable when the probability of collisions is small, as in the case of, e.g., IPv6 IIDs resulting from SLAAC <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> <xref target="RFC8981" format="default" sectionFormat="of" derivedContent="RFC8981"/>.</t>
        <t indent="0" pn="section-7.3-12">For obvious reasons, the transient numeric identifiers generated with this algorithm allow for network activity correlation and fingerprinting within "CONTEXT". However, this is essentially a design goal of this category of transient numeric identifiers.</t>
      </section>
      <section anchor="cat-4-alg" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-category-4-uniqueness-monot">Category #4: Uniqueness, Monotonically Increasing within Context (Hard Failure)</name>
        <section anchor="per-context-counter" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.1">
          <name slugifiedName="name-per-context-counter-algorit">Per-Context Counter Algorithm</name>
          <t indent="0" pn="section-7.4.1-1">One possible way of selecting unique monotonically increasing identifiers (per context) is to employ a per-context counter. Such an algorithm could be described as follows:</t>
          <sourcecode type="c" markers="false" pn="section-7.4.1-2">
    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;
    id_inc = increment() % id_range;

    if( (next_id = lookup_counter(CONTEXT)) == ERROR){
         next_id = min_id + random() % id_range;
    }

    do {
        if ( (max_id - next_id) &gt;= id_inc){
            next_id = next_id + id_inc;
        }
        else {
            next_id = min_id + id_inc - (max_id - next_id);
        }

        if (suitable_id(next_id)){
            store_counter(CONTEXT, next_id);
            return next_id;
        }

        retry = retry - id_inc;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
          <t indent="0" pn="section-7.4.1-3">NOTE:</t>
          <t indent="3" pn="section-7.4.1-4">CONTEXT is the concatenation of all the elements that define a given context.</t>
          <t indent="3" pn="section-7.4.1-5">increment() returns a small integer that is employed to increment the current counter value to obtain the next transient numeric identifier. This value must be larger than or equal to 1, and much smaller than the number of possible values for the numeric identifiers (i.e., "id_range"). Most implementations of this algorithm employ a constant increment of 1. Using a value other than 1 can help mitigate some information leakages (please see below) at the expense of a possible increase in the numeric identifier reuse frequency. The code above makes sure that the increment employed in the algorithm (id_inc) is always smaller than the number of possible values for the numeric identifiers (i.e., "max_id - min_d + 1"). However, as noted above, this value must also be much smaller than the number of possible values for the numeric identifiers.</t>
          <t indent="3" pn="section-7.4.1-6">lookup_counter() is a function that returns the current counter for a given context or an error condition if that counter does not exist.</t>
          <t indent="3" pn="section-7.4.1-7">random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique <xref target="Romailler2020" format="default" sectionFormat="of" derivedContent="Romailler2020"/> can be used.</t>
          <t indent="3" pn="section-7.4.1-8">store_counter() is a function that saves a counter value for a given context.</t>
          <t indent="3" pn="section-7.4.1-9">suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties. </t>
          <t indent="0" pn="section-7.4.1-10">Essentially, whenever a new identifier is to be selected, the algorithm checks whether a counter for the corresponding context exists. If it does, the value of such counter is incremented to obtain the new transient numeric identifier, and the counter is updated. If no counter exists for such context, a new counter is created and initialized to a random value and used as the selected transient numeric identifier. This algorithm produces a per-context counter, which results in one monotonically increasing function for each context. Since each counter is initialized to a random value, the resulting values are unpredictable by an off-path attacker.
</t>
          <t indent="0" pn="section-7.4.1-11">The choice of id_inc has implications on both the security and privacy properties of the resulting identifiers and also on the corresponding interoperability properties. On one hand, minimizing the increments generally minimizes the identifier reuse frequency, albeit at increased predictability. On the other hand, if the increments are randomized, predictability of the resulting identifiers is reduced, and the information leakage produced by global constant increments is mitigated. However, using larger increments than necessary can result in higher numeric identifier reuse frequency.
</t>
          <t indent="0" pn="section-7.4.1-12">This algorithm has the following drawbacks:
</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.4.1-13">
            <li pn="section-7.4.1-13.1">It requires an implementation to store each per-context counter in memory. If, as a result of resource management, the counter for a given context must be removed, the last transient numeric identifier value used for that context will be lost.  Thus, if an identifier subsequently needs to be generated for the same context, the corresponding counter will need to be recreated and reinitialized to a random value, thus possibly leading to reuse/collision of numeric identifiers.
</li>
            <li pn="section-7.4.1-13.2">
Keeping one counter for each possible "context" may in some cases be considered too onerous in terms of memory requirements.
</li>
          </ul>
          <t indent="0" pn="section-7.4.1-14">Otherwise, the identifiers produced by this algorithm do not suffer from the other issues discussed in <xref target="vulns" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
        </section>
        <section anchor="simple-hash" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.2">
          <name slugifiedName="name-simple-prf-based-algorithm">Simple PRF-Based Algorithm</name>
          <t indent="0" pn="section-7.4.2-1">The goal of this algorithm is to produce monotonically increasing transient numeric identifiers (for each given context) with a randomized initial value. For example, if the identifiers being generated must be monotonically increasing for each {Source Address, Destination Address} set, then each possible combination of {Source Address, Destination Address} should have a separate monotonically increasing sequence that starts at a different random value.
</t>
          <t indent="0" pn="section-7.4.2-2">Instead of maintaining a per-context counter (as in the algorithm from <xref target="per-context-counter" format="default" sectionFormat="of" derivedContent="Section 7.4.1"/>), the following algorithm employs a calculated technique to maintain a random offset for each possible context.
</t>
          <sourcecode type="c" markers="false" pn="section-7.4.2-3">
    /* Initialization code */
    counter = 0;

    /* Transient Numeric ID selection function  */

    id_range = max_id - min_id + 1;
    id_inc = increment() % id_range;
    offset = F(CONTEXT, secret_key);
    retry = id_range;

    do {
        next_id = min_id + (offset + counter) % id_range;
        counter = counter + id_inc;

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry = retry - id_inc;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
          <t indent="0" pn="section-7.4.2-4">NOTE:</t>
          <t indent="3" pn="section-7.4.2-5">CONTEXT is the concatenation of all the elements that define a given context. For example, if this algorithm is expected to produce identifiers that are monotonically increasing for each set {Source Address, Destination Address}, CONTEXT should be the concatenation of Source Address and Destination Address.</t>
          <t indent="3" pn="section-7.4.2-6">increment() has the same properties and requirements as those specified for increment() in <xref target="per-context-counter" format="default" sectionFormat="of" derivedContent="Section 7.4.1"/>.</t>
          <t indent="3" pn="section-7.4.2-7">F() is a PRF, with the same properties as those specified for F() in <xref target="cat-3-alg" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</t>
          <t indent="3" pn="section-7.4.2-8">suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties.</t>
          <t indent="0" pn="section-7.4.2-9">In the algorithm above, the function F() provides a stateless, stable, and unpredictable offset for each given context (as identified by "CONTEXT"). Both the "offset" and "counter" variables may take any value within
    the storage type range since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in <xref target="simple-randomization" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/>.  This allows us
    to simply increment the "counter" variable and rely on the
    unsigned integer to wrap around.
          </t>
          <t indent="0" pn="section-7.4.2-10">
The result of F() is no more secure than the secret key, and therefore, "secret_key" must be unknown to the attacker and must be of a reasonable length. "secret_key" must remain stable for a given CONTEXT, since otherwise, the numeric identifiers generated by this algorithm would not have the desired properties (i.e., monotonically increasing for a given CONTEXT). In most cases, "secret_key" should be selected with a PRNG (see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for recommendations on choosing secrets) at an appropriate time and stored in stable or volatile storage (as necessary) for future use.</t>
          <t indent="0" pn="section-7.4.2-11">It should be noted that, since this algorithm uses a global counter ("counter") for selecting identifiers (i.e., all counters share the same increment space), this algorithm results in an information leakage (as described in <xref target="information-leakage" format="default" sectionFormat="of" derivedContent="Section 8.2"/>). For example, if this algorithm was used for selecting TCP ephemeral ports and an attacker could force a client to periodically establish a new TCP connection to an attacker-controlled system (or through an attacker-observable routing path), the attacker could subtract consecutive Source Port values to obtain the number of outgoing TCP connections established globally by the victim host within that time period (up to wrap-around issues and five-tuple collisions, of course). This information leakage could be partially mitigated by employing small random values for the increments (i.e., increment() function), instead of having increment() return the constant "1".</t>
          <t indent="0" pn="section-7.4.2-12">We nevertheless note that an improved mitigation of this information leakage could be more successfully achieved by employing the algorithm from <xref target="double-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.3"/>, instead.</t>
        </section>
        <section anchor="double-hash" numbered="true" toc="exclude" removeInRFC="false" pn="section-7.4.3">
          <name slugifiedName="name-double-prf-algorithm">Double-PRF Algorithm</name>
          <t indent="0" pn="section-7.4.3-1">A trade-off between maintaining a single global "counter" variable and maintaining 2**N "counter" variables (where N is the width of the result of F()) could be achieved as follows. The system would keep an array of TABLE_LENGTH values, which would provide a separation of the increment space into multiple buckets. This improvement could be incorporated into the algorithm from <xref target="simple-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.2"/> as follows:</t>
          <sourcecode type="c" markers="false" pn="section-7.4.3-2">
    /* Initialization code */

    for(i = 0; i &lt; TABLE_LENGTH; i++) {
        table[i] = random();
    }

    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    id_inc = increment() % id_range;
    offset = F(CONTEXT, secret_key1);
    index = G(CONTEXT, secret_key2) % TABLE_LENGTH;
    retry = id_range;

    do {
        next_id = min_id + (offset + table[index]) % id_range;
        table[index] = table[index] + id_inc;

        if (suitable_id(next_id)) {
            return next_id;
        }

       retry = retry - id_inc;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
          <t indent="0" pn="section-7.4.3-3">NOTE:</t>
          <t indent="3" pn="section-7.4.3-4">increment() has the same properties and requirements as those specified for increment() in <xref target="per-context-counter" format="default" sectionFormat="of" derivedContent="Section 7.4.1"/>.</t>
          <t indent="3" pn="section-7.4.3-5">Both F() and G() are PRFs, with the same properties as those required for F() in <xref target="cat-3-alg" format="default" sectionFormat="of" derivedContent="Section 7.3"/>. The results of F() and G() are no more secure than their respective secret keys ("secret_key1" and "secret_key2", respectively), and therefore, both secret keys must be unknown to the attacker and must be of a reasonable length. Both secret keys must remain stable for the given CONTEXT, since otherwise, the transient numeric identifiers generated by this algorithm would not have the desired properties (i.e., monotonically increasing for a given CONTEXT). In most cases, both secret keys should be selected with a PRNG (see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for recommendations on choosing secrets) at an appropriate time and stored in stable or volatile storage (as necessary) for future use.
</t>
          <t indent="3" pn="section-7.4.3-6">
"table[]" could be initialized with random values, as indicated by the initialization code in the pseudocode above.</t>
          <t indent="0" pn="section-7.4.3-7">The "table[]" array assures that successive transient numeric identifiers for a given context will be monotonically increasing. Since the increment space is separated into TABLE_LENGTH different spaces, the identifier reuse frequency will be (probabilistically) lower than that of the algorithm in <xref target="simple-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.2"/>. That is, the generation of an identifier for one given context will not necessarily result in increments in the identifier sequence of other contexts. It is interesting to note that the size of "table[]" does not limit the number of different identifier sequences but rather separates the <strong>increment space</strong> into TABLE_LENGTH different spaces. The selected transient numeric identifier sequence will be obtained by adding the corresponding entry from "table[]" to the value in the "offset" variable, which selects the actual identifier sequence space (as in the algorithm from <xref target="simple-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.2"/>). </t>
          <t indent="0" pn="section-7.4.3-8">An attacker can perform traffic analysis for any "increment
  space"  (i.e., context) into which the attacker has "visibility" -- namely, the attacker can force a system to generate identifiers for G(CONTEXT, secret_key2), where the result of G() identifies the target "increment space". However, the attacker's ability to perform traffic analysis is very reduced when compared to the simple PRF-based identifiers (described in <xref target="simple-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.2"/>) and the predictable linear identifiers (described in <xref target="trad_selection" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>). Additionally, an implementation can further limit the attacker's ability to perform traffic analysis by further separating the increment space (that is, using a larger value for TABLE_LENGTH) and/or by randomizing the increments (i.e., increment() returning a small random number as opposed to the constant "1").</t>
          <t indent="0" pn="section-7.4.3-9">Otherwise, this algorithm does not suffer from the issues discussed in <xref target="vulns" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="vulns" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-common-vulnerabilities-asso">Common Vulnerabilities Associated with Transient Numeric Identifiers</name>
      <section anchor="activity-correlation" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-network-activity-correlatio">Network Activity Correlation</name>
        <t indent="0" pn="section-8.1-1">An identifier that is predictable within a given context allows for network activity correlation within that context.</t>
        <t indent="0" pn="section-8.1-2">For example, a stable IPv6 Interface Identifier allows for network activity to be correlated within the context in which the Interface Identifier is stable <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/>. A stable per-network IPv6 Interface Identifier (as in <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/>) allows for network activity correlation within a network, whereas a constant IPv6 Interface Identifier (which remains constant across networks) allows not only network activity correlation within the same network but also across networks ("host-tracking").
</t>
        <t indent="0" pn="section-8.1-3">Similarly, an implementation that generates TCP ISNs with a global counter could allow for fingerprinting and network activity correlation across networks, since an attacker could passively infer the identity of the victim based on the TCP ISNs employed for subsequent communication instances. Similarly, an implementation that generates predictable IPv6 Identification values could be subject to fingerprinting attacks (see, e.g., <xref target="Bellovin2002" format="default" sectionFormat="of" derivedContent="Bellovin2002"/>).
</t>
      </section>
      <section anchor="information-leakage" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-information-leakage">Information Leakage</name>
        <t indent="0" pn="section-8.2-1">Transient numeric identifiers that result in specific patterns can produce an information leakage to other communicating entities. For example, it is common to generate transient numeric identifiers with an algorithm such as:
</t>
        <sourcecode type="c" markers="false" pn="section-8.2-2">
           ID = offset(CONTEXT) + mono(CONTEXT);
</sourcecode>
        <t indent="0" keepWithNext="true" pn="section-8.2-3">

This generic expression generates identifiers by adding a monotonically increasing function (e.g., linear) to a randomized offset. offset() is constant within a given context, whereas mono() produces a monotonically increasing sequence for the given context. Identifiers generated with this expression will generally be predictable within CONTEXT. </t>
        <t indent="0" pn="section-8.2-4"/>
        <t indent="0" pn="section-8.2-5">The predictability of mono(), irrespective of the predictability of offset(), can leak information that may be of use to attackers. For example, a node that selects transport-protocol ephemeral port numbers, as in:</t>
        <sourcecode type="c" markers="false" pn="section-8.2-6">
           ephemeral_port = offset(IP_Dst_Addr) + mono()
</sourcecode>
        <t indent="0" keepWithNext="true" pn="section-8.2-7">
that is, with a per-destination offset but a global mono() function (e.g., a global counter), will leak information about the total number of outgoing connections that have been issued by the vulnerable implementation.</t>
        <t indent="0" pn="section-8.2-8"/>
        <t indent="0" pn="section-8.2-9">Similarly, a node that generates IPv6 Identification values as in:
</t>
        <sourcecode type="c" markers="false" pn="section-8.2-10">
           ID = offset(IP_Src_Addr, IP_Dst_Addr) + mono()
</sourcecode>
        <t indent="0" pn="section-8.2-11">
will leak out information about the total number of fragmented packets that have been transmitted by the vulnerable implementation. The vulnerabilities described in <xref target="Sanfilippo1998a" format="default" sectionFormat="of" derivedContent="Sanfilippo1998a"/>, <xref target="Sanfilippo1998b" format="default" sectionFormat="of" derivedContent="Sanfilippo1998b"/>, and <xref target="Sanfilippo1999" format="default" sectionFormat="of" derivedContent="Sanfilippo1999"/> are all associated with the use of a global mono() function (i.e., with a global and constant "CONTEXT") -- particularly when it is a linear function (constant increments of 1).
</t>
        <t indent="0" pn="section-8.2-12">Predicting transient numeric identifiers can be of help for other types of attacks. For example, predictable TCP ISNs can open the door to trivial connection-reset and data injection attacks (see <xref target="injection-attacks" format="default" sectionFormat="of" derivedContent="Section 8.6"/>).
</t>
      </section>
      <section anchor="fingerprinting" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-fingerprinting">Fingerprinting</name>
        <t indent="0" pn="section-8.3-1">Fingerprinting is the capability of an attacker to identify or reidentify a visiting user, user agent, or device via configuration settings or other observable characteristics. Observable protocol objects and characteristics can be employed to identify/reidentify
various entities. These entities can range from the underlying hardware or operating
system (OS) (vendor, type, and version) to the user. <xref target="EFF" format="default" sectionFormat="of" derivedContent="EFF"/> illustrates web-browser-based fingerprinting, but
similar techniques can be applied at other layers and protocols, whether
alternatively or in conjunction with it.</t>
        <t indent="0" pn="section-8.3-2">
Transient numeric identifiers are one of the observable protocol components that could be leveraged for fingerprinting purposes. That is, an attacker could sample transient numeric identifiers to infer the algorithm (and its associated parameters, if any) for generating such identifiers, possibly revealing the underlying OS vendor, type, and version. This information could possibly be further leveraged in conjunction with other fingerprinting techniques and sources.
</t>
        <t indent="0" pn="section-8.3-3">
Evasion of protocol-stack fingerprinting can prove to be a very difficult task, i.e., most systems make use of a wide variety of protocols, each of which have a large number of parameters that can be set to arbitrary values or generated with a variety of algorithms with multiple parameters.

</t>
        <aside pn="section-8.3-4">
          <t indent="0" pn="section-8.3-4.1">NOTE: General protocol-based fingerprinting is discussed in <xref target="RFC6973" format="default" sectionFormat="of" derivedContent="RFC6973"/>,
   along with guidelines to mitigate the associated  vulnerability.
   <xref target="Fyodor1998" format="default" sectionFormat="of" derivedContent="Fyodor1998"/> and <xref target="Fyodor2006" format="default" sectionFormat="of" derivedContent="Fyodor2006"/> are classic references
   on OS detection via TCP/IP stack fingerprinting.
   Network Mapper <xref target="nmap" format="default" sectionFormat="of" derivedContent="nmap"/> is probably the most popular tool for remote OS
   identification via active TCP/IP stack fingerprinting. p0f <xref target="Zalewski2012" format="default" sectionFormat="of" derivedContent="Zalewski2012"/>,
   on the other hand, is a tool for performing remote OS detection via
   passive TCP/IP stack fingerprinting. Finally, <xref target="TBIT" format="default" sectionFormat="of" derivedContent="TBIT"/> is a TCP
   fingerprinting tool that aims at characterizing the behavior of a
   remote TCP peer based on active probes, which has been widely
   used in the research community.
</t>
        </aside>
        <t indent="0" pn="section-8.3-5">
Algorithms that, from the perspective of an observer (e.g., the legitimate communicating peer), result in specific values or patterns will allow for at least some level of fingerprinting. For example,
the algorithm from <xref target="cat-3-alg" format="default" sectionFormat="of" derivedContent="Section 7.3"/> will typically allow fingerprinting within the context where the resulting identifiers are stable. Similarly, the algorithms from <xref target="cat-4-alg" format="default" sectionFormat="of" derivedContent="Section 7.4"/> will result in monotonically increasing sequences within a given context, thus allowing for at least some level of fingerprinting (when the other communicating entity can correlate different sampled identifiers as belonging to the same monotonically increasing sequence).
</t>
        <t indent="0" pn="section-8.3-6">
Thus, where possible, algorithms from <xref target="cat-1-alg" format="default" sectionFormat="of" derivedContent="Section 7.1"/> should be preferred over algorithms that result in specific values or patterns.
</t>
      </section>
      <section anchor="id-semantics" numbered="true" toc="include" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-exploitation-of-the-semanti">Exploitation of the Semantics of Transient Numeric Identifiers</name>
        <t indent="0" pn="section-8.4-1">Identifiers that are not semantically opaque tend to be more predictable than semantically opaque identifiers. For example, a Media Access Control (MAC) address contains an  Organizationally Unique Identifier (OUI), which may identify the vendor that manufactured the corresponding network interface card. This can be leveraged by an attacker trying to "guess" MAC addresses, who has some knowledge about the possible Network Interface Card (NIC) vendor.</t>
        <t indent="0" pn="section-8.4-2"><xref target="RFC7707" format="default" sectionFormat="of" derivedContent="RFC7707"/> discusses a number of techniques to reduce the search space when performing IPv6 address-scanning attacks by leveraging the semantics of IPv6 IIDs.
</t>
      </section>
      <section anchor="id-collisions" numbered="true" toc="include" removeInRFC="false" pn="section-8.5">
        <name slugifiedName="name-exploitation-of-collisions-">Exploitation of Collisions of Transient Numeric Identifiers</name>
        <t indent="0" pn="section-8.5-1">In many cases, the collision of transient network identifiers can have a hard failure severity (or result in a hard failure severity if an attacker can cause multiple collisions deterministically, one after another). For example, predictable IP Identification values open the door to Denial of Service (DoS) attacks (see, e.g., <xref target="RFC5722" format="default" sectionFormat="of" derivedContent="RFC5722"/>.).
</t>
      </section>
      <section anchor="injection-attacks" numbered="true" toc="include" removeInRFC="false" pn="section-8.6">
        <name slugifiedName="name-exploitation-of-predictable">Exploitation of Predictable Transient Numeric Identifiers for Injection Attacks</name>
        <t indent="0" pn="section-8.6-1">Some protocols rely on "sequence numbers" for the validation of incoming packets. For example, TCP employs sequence numbers for reassembling TCP segments, while IPv4 and IPv6 employ Identification values for reassembling IPv4 and IPv6 fragments (respectively). Lacking built-in cryptographic mechanisms for validating packets, these protocols are therefore vulnerable to on-path data (see, e.g., <xref target="Joncheray1995" format="default" sectionFormat="of" derivedContent="Joncheray1995"/>)  and/or control-information (see, e.g., <xref target="RFC4953" format="default" sectionFormat="of" derivedContent="RFC4953"/> and <xref target="RFC5927" format="default" sectionFormat="of" derivedContent="RFC5927"/>) injection attacks. The extent to which these protocols may resist off-path (i.e., "blind") injection attacks depends on whether the associated "sequence numbers" are predictable and the effort required to successfully predict a valid "sequence number" (see, e.g., <xref target="RFC4953" format="default" sectionFormat="of" derivedContent="RFC4953"/> and <xref target="RFC5927" format="default" sectionFormat="of" derivedContent="RFC5927"/>).
</t>
        <t indent="0" pn="section-8.6-2">We note that the use of unpredictable "sequence numbers" is a completely ineffective mitigation for on-path injection attacks and also a mostly ineffective mitigation for off-path (i.e., "blind") injection attacks.
However, many legacy protocols (such as TCP) do not incorporate cryptographic mitigations as part of the core protocol but rather as optional features (see, e.g., <xref target="RFC5925" format="default" sectionFormat="of" derivedContent="RFC5925"/>), if available at all.
Additionally, ad hoc use of cryptographic mitigations might not be sufficient to relieve a protocol implementation of generating appropriate transient numeric identifiers. For example, use of the Transport Layer Security (TLS) protocol <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> with TCP will protect the application protocol but will not help to mitigate, e.g., TCP-based connection-reset attacks (see, e.g., <xref target="RFC4953" format="default" sectionFormat="of" derivedContent="RFC4953"/>). Similarly, use of SEcure Neighbor Discovery (SEND) <xref target="RFC3971" format="default" sectionFormat="of" derivedContent="RFC3971"/> will still imply reliance on the successful reassembly of IPv6 fragments in those cases where SEND packets do not fit into the link Maximum Transmission Unit (MTU) (see <xref target="RFC6980" format="default" sectionFormat="of" derivedContent="RFC6980"/>).</t>
      </section>
      <section anchor="crypto-analisis" numbered="true" toc="include" removeInRFC="false" pn="section-8.7">
        <name slugifiedName="name-cryptanalysis">Cryptanalysis</name>
        <t indent="0" pn="section-8.7-1">A number of algorithms discussed in this document (such as those described in Sections <xref target="simple-hash" format="counter" sectionFormat="of" derivedContent="7.4.2"/> and <xref target="double-hash" format="counter" sectionFormat="of" derivedContent="7.4.3"/>) rely on PRFs. Implementations that employ weak PRFs or keys of inappropriate size can be subject to cryptanalysis, where an attacker can obtain the secret key employed for the PRF, predict numeric identifiers, etc. </t>
        <t indent="0" pn="section-8.7-2">Furthermore, an implementation that overloads the semantics of the secret key can result in more trivial cryptanalysis, possibly resulting in the leakage of the value employed for the secret key.
</t>
        <aside pn="section-8.7-3">
          <t indent="0" pn="section-8.7-3.1">NOTE: <xref target="IPID-DEV" format="default" sectionFormat="of" derivedContent="IPID-DEV"/> describes two vulnerable transient numeric identifier generators that employ cryptographically weak hash functions. Additionally, one of such implementations employs 32 bits of a kernel address as the secret key for a hash function, and therefore, successful cryptanalysis leaks the aforementioned kernel address, allowing for Kernel Address Space Layout Randomization (KASLR) <xref target="KASLR" format="default" sectionFormat="of" derivedContent="KASLR"/> bypass.</t>
        </aside>
      </section>
    </section>
    <section anchor="vuln-cats" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-vulnerability-assessment-of">Vulnerability Assessment of Transient Numeric Identifiers</name>
      <t indent="0" pn="section-9-1">
The following subsections analyze possible vulnerabilities associated with the algorithms described in <xref target="common-algorithms" format="default" sectionFormat="of" derivedContent="Section 7"/>.
</t>
      <section anchor="cat-1-vuln" numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-category-1-uniqueness-soft-f">Category #1: Uniqueness (Soft Failure)</name>
        <t indent="0" pn="section-9.1-1">Possible vulnerabilities associated with the algorithms from <xref target="cat-1-alg" format="default" sectionFormat="of" derivedContent="Section 7.1"/> include the following:
</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.1-2">
          <li pn="section-9.1-2.1">use of flawed PRNGs (please see, e.g., <xref target="Zalewski2001" format="default" sectionFormat="of" derivedContent="Zalewski2001"/>, <xref target="Zalewski2002" format="default" sectionFormat="of" derivedContent="Zalewski2002"/>, <xref target="Klein2007" format="default" sectionFormat="of" derivedContent="Klein2007"/>, and <xref target="CVEs" format="default" sectionFormat="of" derivedContent="CVEs"/>)</li>
          <li pn="section-9.1-2.2">inadvertently affecting the distribution of an otherwise suitable PRNG (please see, e.g., <xref target="Romailler2020" format="default" sectionFormat="of" derivedContent="Romailler2020"/>)</li>
        </ul>
        <t indent="0" pn="section-9.1-3">Where available, CSPRNGs should be preferred over regular PRNGs, such as, e.g., POSIX random(3) implementations. In scenarios where a CSPRNG is not readily available, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision.

</t>
        <aside pn="section-9.1-4">
          <t indent="0" pn="section-9.1-4.1">NOTE: Please see <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> regarding randomness requirements for security. <xref target="Aumasson2018" format="default" sectionFormat="of" derivedContent="Aumasson2018"/>, <xref target="Press1992" format="default" sectionFormat="of" derivedContent="Press1992"/>, and <xref target="Knuth1983" format="default" sectionFormat="of" derivedContent="Knuth1983"/> discuss theoretical and practical aspects of random number generation and provide guidance on how to evaluate PRNGs.</t>
        </aside>
        <t indent="0" pn="section-9.1-5">When employing a PRNG, many implementations "adapt" the length of its output with a modulo operator (e.g., C language's "%"), possibly changing the distribution of the output of the PRNG.</t>
        <t indent="0" pn="section-9.1-6">
For example, consider an implementation that employs the following code:

</t>
        <sourcecode type="c" markers="false" pn="section-9.1-7">
           id = random() % 50000;
</sourcecode>
        <t indent="0" keepWithNext="true" pn="section-9.1-8">
This example implementation means to obtain a transient numeric identifier in the range 0-49999. If random() produces, e.g., a pseudorandom number of 16 bits (with uniform distribution), the selected transient numeric identifier will have a nonuniform distribution with the numbers in the range 0-15535 having double frequency than the numbers in the range 15536-49999.
</t>
        <t indent="0" pn="section-9.1-9"/>
        <aside pn="section-9.1-10">
          <t indent="0" pn="section-9.1-10.1">NOTE: For example, in our sample code, both an output of 10 and output of 50010 from the random() function will result in an "id" value of 10.
</t>
        </aside>
        <t indent="0" pn="section-9.1-11">
This effect is reduced if the PRNG produces an output that is much longer than the length implied by the modulo operation. We note that to preserve a uniform distribution, the rejection sampling technique <xref target="Romailler2020" format="default" sectionFormat="of" derivedContent="Romailler2020"/> can be used.
</t>
        <t indent="0" pn="section-9.1-12">
Use of algorithms other than PRNGs for generating identifiers of this category is discouraged.
</t>
      </section>
      <section anchor="cat-2-vuln" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-category-2-uniqueness-hard-f">Category #2: Uniqueness (Hard Failure)</name>
        <t indent="0" pn="section-9.2-1">As noted in <xref target="cat-2-alg" format="default" sectionFormat="of" derivedContent="Section 7.2"/>, this category can employ the same algorithms as Category #4, since a monotonically increasing sequence tends to minimize the transient numeric identifier reuse frequency. Therefore, the vulnerability analysis in <xref target="cat-4-vuln" format="default" sectionFormat="of" derivedContent="Section 9.4"/> also applies to this category.
</t>
        <t indent="0" pn="section-9.2-2">Additionally, as noted in <xref target="cat-2-alg" format="default" sectionFormat="of" derivedContent="Section 7.2"/>, some transient numeric identifiers of this category might be able to use the algorithms from  <xref target="cat-1-alg" format="default" sectionFormat="of" derivedContent="Section 7.1"/>, in which case the same considerations as in <xref target="cat-1-vuln" format="default" sectionFormat="of" derivedContent="Section 9.1"/> would apply.
</t>
      </section>
      <section anchor="cat-3-vuln" numbered="true" toc="include" removeInRFC="false" pn="section-9.3">
        <name slugifiedName="name-category-3-uniqueness-stable">Category #3: Uniqueness, Stable within Context (Soft Failure)</name>
        <t indent="0" pn="section-9.3-1">Possible vulnerabilities associated with the algorithms from <xref target="cat-3-alg" format="default" sectionFormat="of" derivedContent="Section 7.3"/> are the following:
</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.3-2">
          <li pn="section-9.3-2.1">Use of weak PRFs or inappropriate secret keys (whether inappropriate selection or inappropriate size) could allow for cryptanalysis, which could eventually be exploited by an attacker to predict future transient numeric identifiers.</li>
          <li pn="section-9.3-2.2">Since the algorithm generates a unique and stable identifier within a specified context, it may allow for network activity correlation and fingerprinting within the specified context.</li>
        </ul>
      </section>
      <section anchor="cat-4-vuln" numbered="true" toc="include" removeInRFC="false" pn="section-9.4">
        <name slugifiedName="name-category-4-uniqueness-monoto">Category #4: Uniqueness, Monotonically Increasing within Context (Hard Failure)</name>
        <t indent="0" pn="section-9.4-1">The algorithm described in <xref target="per-context-counter" format="default" sectionFormat="of" derivedContent="Section 7.4.1"/> for generating identifiers of Category #4 will result in an identifiable pattern (i.e., a monotonically increasing sequence) for the transient numeric identifiers generated for each CONTEXT, and thus will allow for fingerprinting and network activity correlation within each CONTEXT.
</t>
        <t indent="0" pn="section-9.4-2">On the other hand, a simple way to generalize and analyze the algorithms described in Sections <xref target="simple-hash" format="counter" sectionFormat="of" derivedContent="7.4.2"/> and <xref target="double-hash" format="counter" sectionFormat="of" derivedContent="7.4.3"/> for generating identifiers of Category #4 is as follows:
        </t>
        <sourcecode type="c" markers="false" pn="section-9.4-3">
    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;
    id_inc = increment() % id_range;

    do {
        update_mono(CONTEXT, id_inc);
        next_id = min_id + (offset(CONTEXT) + \
                            mono(CONTEXT)) % id_range;

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry = retry - id_inc;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
        <t indent="0" pn="section-9.4-4">NOTE:</t>
        <t indent="3" pn="section-9.4-5">increment() returns a small integer that is employed to generate a monotonically increasing function. Most implementations employ a constant value for "increment()" (usually 1). The value returned by increment() must be much smaller than the value computed for "id_range".
</t>
        <t indent="3" pn="section-9.4-6">update_mono(CONTEXT, id_inc) increments the counter corresponding to CONTEXT by "id_inc".
</t>
        <t indent="3" pn="section-9.4-7">mono(CONTEXT) reads the counter corresponding to CONTEXT.
</t>
        <t indent="0" pn="section-9.4-8">Essentially, an identifier (next_id) is generated by adding a monotonically increasing function (mono()) to an offset value, which is unknown to the attacker and stable for given context (CONTEXT).</t>
        <t indent="0" pn="section-9.4-9">The following aspects of the algorithm should be considered:


</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.4-10">
          <li pn="section-9.4-10.1">For the most part, it is the offset() function that results in identifiers that are unpredictable by an off-patch attacker. While the resulting sequence is known to be monotonically increasing, the use of a randomized offset value makes the resulting values unknown to the attacker.</li>
          <li pn="section-9.4-10.2">The most straightforward "stateless" implementation of offset() is with a PRF that takes the values that identify the context and a secret key (not shown in the figure above) as arguments.
</li>
          <li pn="section-9.4-10.3">
One possible implementation of mono() would be to have mono() internally employ a single counter (as in the algorithm from <xref target="simple-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.2"/>) or map the increments for different contexts into a number of counters/buckets, such that the number of counters that need to be maintained in memory is reduced (as in the "Double-PRF Algorithm" from <xref target="double-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.3"/>).
</li>
          <li pn="section-9.4-10.4">In all cases, a monotonically increasing function is implemented by incrementing the previous value of a counter by increment() units. In the most trivial case, increment() could return the constant "1". But increment() could also be implemented to return small random integers such that the increments are unpredictable (see <xref target="random-increments" format="default" sectionFormat="of" derivedContent="Appendix A.2"/> of this document). This represents a trade-off between the unpredictability of the resulting transient numeric identifiers and the transient numeric identifier reuse frequency.
</li>
        </ul>
        <t indent="0" pn="section-9.4-11">Considering the generic algorithm illustrated above, we can identify the following possible vulnerabilities:
</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.4-12">
          <li pn="section-9.4-12.1">Since the algorithms for this category are similar to those of <xref target="cat-3-vuln" format="default" sectionFormat="of" derivedContent="Section 9.3"/>, with the addition of a monotonically increasing function, all the issues discussed in <xref target="cat-3-vuln" format="default" sectionFormat="of" derivedContent="Section 9.3"/> ("Category #3: Uniqueness, Stable within Context (Soft Failure)") also apply to this case.
</li>
          <li pn="section-9.4-12.2">mono() can be correlated to the number of identifiers generated for a given context (CONTEXT). Thus, if mono() spans more than the necessary context, the "increments" could be leaked to other parties, thus disclosing information about the number of identifiers that have been generated by the algorithm for all contexts. This information disclosure becomes more evident when an implementation employs a constant increment of 1.


For example, an implementation where mono() is actually a single global counter will unnecessarily leak information about the number of identifiers that have been generated by the algorithm (globally, for all contexts). <xref target="Fyodor2003" format="default" sectionFormat="of" derivedContent="Fyodor2003"/> describes one example of how such information leakages can be exploited. We note that limiting the span of the increment space will require a larger number of counters to be stored in memory (i.e., a larger value for the TABLE_LENGTH parameter of the algorithm in <xref target="double-hash" format="default" sectionFormat="of" derivedContent="Section 7.4.3"/>).
</li>
          <li pn="section-9.4-12.3">Transient numeric identifiers generated with the algorithms described in Sections <xref target="simple-hash" format="counter" sectionFormat="of" derivedContent="7.4.2"/> and <xref target="double-hash" format="counter" sectionFormat="of" derivedContent="7.4.3"/> will normally allow for fingerprinting within CONTEXT since, for such context, the resulting identifiers will have an identifiable pattern (i.e., a monotonically increasing sequence).
</li>
        </ul>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-10-1">This document has no IANA actions.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">This entire document is about the security and privacy implications of transient numeric identifiers. <xref target="RFC9416" format="default" sectionFormat="of" derivedContent="RFC9416"/> recommends that protocol specifications specify the interoperability requirements of their transient numeric identifiers, perform a vulnerability assessment of their transient numeric identifiers, and recommend an algorithm for generating each of their transient numeric identifiers. This document analyzes possible algorithms (and their implications) that could be employed to comply with the interoperability requirements of the most common categories of transient numeric identifiers while minimizing the associated negative security and privacy implications.</t>
    </section>
  </middle>
  <back>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791" quoteTitle="true" derivedAnchor="RFC0791">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793" quoteTitle="true" derivedAnchor="RFC0793">
          <front>
            <title>Transmission Control Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="RFC" value="793"/>
          <seriesInfo name="DOI" value="10.17487/RFC0793"/>
        </reference>
        <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" quoteTitle="true" derivedAnchor="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t indent="0">This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC1321" target="https://www.rfc-editor.org/info/rfc1321" quoteTitle="true" derivedAnchor="RFC1321">
          <front>
            <title>The MD5 Message-Digest Algorithm</title>
            <author fullname="R. Rivest" initials="R." surname="Rivest"/>
            <date month="April" year="1992"/>
            <abstract>
              <t indent="0">This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1321"/>
          <seriesInfo name="DOI" value="10.17487/RFC1321"/>
        </reference>
        <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460" quoteTitle="true" derivedAnchor="RFC2460">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="December" year="1998"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2460"/>
          <seriesInfo name="DOI" value="10.17487/RFC2460"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4291" quoteTitle="true" derivedAnchor="RFC4291">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="February" year="2006"/>
            <abstract>
              <t indent="0">This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
              <t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4291"/>
          <seriesInfo name="DOI" value="10.17487/RFC4291"/>
        </reference>
        <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862" quoteTitle="true" derivedAnchor="RFC4862">
          <front>
            <title>IPv6 Stateless Address Autoconfiguration</title>
            <author fullname="S. Thomson" initials="S." surname="Thomson"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4862"/>
          <seriesInfo name="DOI" value="10.17487/RFC4862"/>
        </reference>
        <reference anchor="RFC5722" target="https://www.rfc-editor.org/info/rfc5722" quoteTitle="true" derivedAnchor="RFC5722">
          <front>
            <title>Handling of Overlapping IPv6 Fragments</title>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <date month="December" year="2009"/>
            <abstract>
              <t indent="0">The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5722"/>
          <seriesInfo name="DOI" value="10.17487/RFC5722"/>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="RFC5925" target="https://www.rfc-editor.org/info/rfc5925" quoteTitle="true" derivedAnchor="RFC5925">
          <front>
            <title>The TCP Authentication Option</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5925"/>
          <seriesInfo name="DOI" value="10.17487/RFC5925"/>
        </reference>
        <reference anchor="RFC6056" target="https://www.rfc-editor.org/info/rfc6056" quoteTitle="true" derivedAnchor="RFC6056">
          <front>
            <title>Recommendations for Transport-Protocol Port Randomization</title>
            <author fullname="M. Larsen" initials="M." surname="Larsen"/>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="January" year="2011"/>
            <abstract>
              <t indent="0">During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="156"/>
          <seriesInfo name="RFC" value="6056"/>
          <seriesInfo name="DOI" value="10.17487/RFC6056"/>
        </reference>
        <reference anchor="RFC6151" target="https://www.rfc-editor.org/info/rfc6151" quoteTitle="true" derivedAnchor="RFC6151">
          <front>
            <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <date month="March" year="2011"/>
            <abstract>
              <t indent="0">This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6151"/>
          <seriesInfo name="DOI" value="10.17487/RFC6151"/>
        </reference>
        <reference anchor="RFC6191" target="https://www.rfc-editor.org/info/rfc6191" quoteTitle="true" derivedAnchor="RFC6191">
          <front>
            <title>Reducing the TIME-WAIT State Using TCP Timestamps</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="April" year="2011"/>
            <abstract>
              <t indent="0">This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="159"/>
          <seriesInfo name="RFC" value="6191"/>
          <seriesInfo name="DOI" value="10.17487/RFC6191"/>
        </reference>
        <reference anchor="RFC6437" target="https://www.rfc-editor.org/info/rfc6437" quoteTitle="true" derivedAnchor="RFC6437">
          <front>
            <title>IPv6 Flow Label Specification</title>
            <author fullname="S. Amante" initials="S." surname="Amante"/>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <author fullname="J. Rajahalme" initials="J." surname="Rajahalme"/>
            <date month="November" year="2011"/>
            <abstract>
              <t indent="0">This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.</t>
              <t indent="0">The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6437"/>
          <seriesInfo name="DOI" value="10.17487/RFC6437"/>
        </reference>
        <reference anchor="RFC6528" target="https://www.rfc-editor.org/info/rfc6528" quoteTitle="true" derivedAnchor="RFC6528">
          <front>
            <title>Defending against Sequence Number Attacks</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="S. Bellovin" initials="S." surname="Bellovin"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6528"/>
          <seriesInfo name="DOI" value="10.17487/RFC6528"/>
        </reference>
        <reference anchor="RFC7217" target="https://www.rfc-editor.org/info/rfc7217" quoteTitle="true" derivedAnchor="RFC7217">
          <front>
            <title>A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="April" year="2014"/>
            <abstract>
              <t indent="0">This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7217"/>
          <seriesInfo name="DOI" value="10.17487/RFC7217"/>
        </reference>
        <reference anchor="RFC7323" target="https://www.rfc-editor.org/info/rfc7323" quoteTitle="true" derivedAnchor="RFC7323">
          <front>
            <title>TCP Extensions for High Performance</title>
            <author fullname="D. Borman" initials="D." surname="Borman"/>
            <author fullname="B. Braden" initials="B." surname="Braden"/>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
            <author fullname="R. Scheffenegger" initials="R." role="editor" surname="Scheffenegger"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.</t>
              <t indent="0">This document obsoletes RFC 1323 and describes changes from it.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7323"/>
          <seriesInfo name="DOI" value="10.17487/RFC7323"/>
        </reference>
        <reference anchor="RFC8064" target="https://www.rfc-editor.org/info/rfc8064" quoteTitle="true" derivedAnchor="RFC8064">
          <front>
            <title>Recommendation on Stable IPv6 Interface Identifiers</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="W. Liu" initials="W." surname="Liu"/>
            <date month="February" year="2017"/>
            <abstract>
              <t indent="0">This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8064"/>
          <seriesInfo name="DOI" value="10.17487/RFC8064"/>
        </reference>
        <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8981" quoteTitle="true" derivedAnchor="RFC8981">
          <front>
            <title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="R. Draves" initials="R." surname="Draves"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8981"/>
          <seriesInfo name="DOI" value="10.17487/RFC8981"/>
        </reference>
        <reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9293" quoteTitle="true" derivedAnchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="ARC4RANDOM" target="https://man.openbsd.org/arc4random" quoteTitle="true" derivedAnchor="ARC4RANDOM">
          <front>
            <title>arc4random(3)</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="September" year="2019"/>
          </front>
          <refcontent>Library Functions Manual</refcontent>
        </reference>
        <reference anchor="Aumasson2018" quoteTitle="true" derivedAnchor="Aumasson2018">
          <front>
            <title>Serious Cryptography: A Practical Introduction to Modern Encryption</title>
            <author initials="J-P." surname="Aumasson" fullname="Jean-Philippe Aumasson">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2017"/>
          </front>
          <seriesInfo name="ISBN-10" value="1-59327-826-8"/>
          <refcontent>No Starch Press, Inc.</refcontent>
        </reference>
        <reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb/papers/ipext.pdf" quoteTitle="true" derivedAnchor="Bellovin1989">
          <front>
            <title>Security Problems in the TCP/IP Protocol Suite</title>
            <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="April" year="1989"/>
          </front>
          <refcontent>Computer Communications Review, Vol. 19, No. 2, pp. 32-48</refcontent>
        </reference>
        <reference anchor="Bellovin2002" target="https://www.cs.columbia.edu/~smb/papers/fnat.pdf" quoteTitle="true" derivedAnchor="Bellovin2002">
          <front>
            <title>A Technique for Counting NATted Hosts</title>
            <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="November"/>
          </front>
          <seriesInfo name="ISBN" value="1-58113-603-X/02/0011"/>
          <refcontent>IMW'02, Marseille, France</refcontent>
        </reference>
        <reference anchor="BLAKE3" target="https://blake3.io/" quoteTitle="true" derivedAnchor="BLAKE3">
          <front>
            <title>BLAKE3: one function, fast everywhere</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="September"/>
          </front>
        </reference>
        <reference anchor="C11" quoteTitle="true" derivedAnchor="C11">
          <front>
            <title>Information technology - Programming languages - C</title>
            <author>
              <organization showOnFrontPage="true">ISO/IEC</organization>
            </author>
            <date year="2018" month="June"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9899:2018"/>
        </reference>
        <reference anchor="CPNI-TCP" target="https://www.si6networks.com/files/publications/tn-03-09-security-assessment-TCP.pdf" quoteTitle="true" derivedAnchor="CPNI-TCP">
          <front>
            <title>Security Assessment of the Transmission Control Protocol (TCP)</title>
            <author>
              <organization showOnFrontPage="true">Centre for the Protection of National Infrastructure (CPNI)</organization>
            </author>
            <date month="February" year="2009"/>
          </front>
          <seriesInfo name="CPNI Technical Note" value="3/2009"/>
        </reference>
        <reference anchor="CVEs" target="https://www.gont.com.ar/miscellanea/prng-cves/" quoteTitle="true" derivedAnchor="CVEs">
          <front>
            <title>Vulnerability Advisories for PRNGs</title>
            <author>
              <organization showOnFrontPage="true">NVD</organization>
            </author>
          </front>
        </reference>
        <reference anchor="EFF" target="https://coveryourtracks.eff.org/" quoteTitle="true" derivedAnchor="EFF">
          <front>
            <title>Cover your tracks: See how trackers view your browser</title>
            <author>
              <organization showOnFrontPage="true">EFF</organization>
            </author>
          </front>
        </reference>
        <reference anchor="FIPS-SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf" quoteTitle="true" derivedAnchor="FIPS-SHS">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization showOnFrontPage="true">NIST</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="FIPS PUB" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>
        <reference anchor="Fyodor1998" target="http://www.phrack.org/archives/issues/54/9.txt" quoteTitle="true" derivedAnchor="Fyodor1998">
          <front>
            <title>Remote OS detection via TCP/IP Stack FingerPrinting</title>
            <author>
              <organization showOnFrontPage="true">Fyodor</organization>
            </author>
            <date year="1998" month="December"/>
          </front>
          <refcontent>Phrack Magazine, Volume 8, Issue 54</refcontent>
        </reference>
        <reference anchor="Fyodor2003" target="https://nmap.org/presentations/CanSecWest03/CD_Content/idlescan_paper/idlescan.html" quoteTitle="true" derivedAnchor="Fyodor2003">
          <front>
            <title>Idle Scanning and related IPID games</title>
            <author>
              <organization showOnFrontPage="true">Fyodor</organization>
            </author>
            <date year="2003"/>
          </front>
        </reference>
        <reference anchor="Fyodor2006" target="https://nmap.org/book/osdetect.html" quoteTitle="true" derivedAnchor="Fyodor2006">
          <front>
            <title>Chapter 8. Remote OS Detection</title>
            <author initials="G." surname="Lyon" fullname="Gordon Lyon">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="January"/>
          </front>
        </reference>
        <reference anchor="GETENTROPY" target="https://man7.org/linux/man-pages/man3/getentropy.3.html" quoteTitle="true" derivedAnchor="GETENTROPY">
          <front>
            <title>getentropy(3)</title>
            <author>
              <organization showOnFrontPage="true">Linux</organization>
            </author>
            <date month="March" year="2021"/>
          </front>
          <refcontent>Linux Programmer's Manual</refcontent>
        </reference>
        <reference anchor="IANA-PROT" target="https://www.iana.org/protocols" quoteTitle="true" derivedAnchor="IANA-PROT">
          <front>
            <title>Protocol Registries</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IPID-DEV" target="https://arxiv.org/pdf/1906.10478.pdf" quoteTitle="true" derivedAnchor="IPID-DEV">
          <front>
            <title>From IP ID to Device ID and KASLR Bypass (Extended Version)</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Pinkas" fullname="Benny Pinkas">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="October"/>
          </front>
          <seriesInfo name="DOI" value="10.48550/arXiv.1906.10478"/>
        </reference>
        <reference anchor="Joncheray1995" target="https://www.usenix.org/legacy/publications/library/proceedings/security95/full_papers/joncheray.pdf" quoteTitle="true" derivedAnchor="Joncheray1995">
          <front>
            <title>Simple Active Attack Against TCP</title>
            <author initials="L." surname="Joncheray" fullname="Laurent Joncheray">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1995" month="June"/>
          </front>
          <refcontent>Proceedings of the Fifth USENIX UNIX Security Symposium</refcontent>
        </reference>
        <reference anchor="KASLR" target="https://pax.grsecurity.net/docs/aslr.txt" quoteTitle="true" derivedAnchor="KASLR">
          <front>
            <title>Address Space Layout Randomization</title>
            <author>
              <organization showOnFrontPage="true">PaX Team</organization>
            </author>
          </front>
        </reference>
        <reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf" quoteTitle="true" derivedAnchor="Klein2007">
          <front>
            <title>OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2007"/>
          </front>
        </reference>
        <reference anchor="Knuth1983" quoteTitle="true" derivedAnchor="Knuth1983">
          <front>
            <title>The Art of Computer Programming</title>
            <author initials="D." surname="Knuth" fullname="Donald Knuth">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1981" month="January"/>
          </front>
          <refcontent>Volume 2 (Seminumerical Algorithms), 2nd Ed., Reading, Massachusetts, Addison-Wesley Publishing Company</refcontent>
        </reference>
        <reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/papers/117.pdf" quoteTitle="true" derivedAnchor="Morris1985">
          <front>
            <title>A Weakness in the 4.2BSD UNIX TCP/IP Software</title>
            <author initials="R." surname="Morris" fullname="Robert T. Morris">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1985" month="February"/>
          </front>
          <refcontent>CSTR 117, AT&amp;T Bell Laboratories, Murray Hill, NJ</refcontent>
        </reference>
        <reference anchor="nmap" target="https://nmap.org/" quoteTitle="true" derivedAnchor="nmap">
          <front>
            <title>Nmap: Free Security Scanner For Network Exploration and Audit</title>
            <author>
              <organization showOnFrontPage="true">nmap</organization>
            </author>
            <date year="2020"/>
          </front>
        </reference>
        <reference anchor="POSIX" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2018.8277153" derivedAnchor="POSIX">
          <front>
            <title>IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date year="2018" month="January"/>
          </front>
          <seriesInfo name="IEEE Std" value="1003.1-2017"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8277153"/>
        </reference>
        <reference anchor="Press1992" quoteTitle="true" derivedAnchor="Press1992">
          <front>
            <title>Numerical Recipes in C: The Art of Scientific Computing</title>
            <author initials="W." surname="Press" fullname="William H. Press">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Teukolsky" fullname="Saul A. Teukolsky">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Vetterling" fullname="William  T.  Vetterling">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Flannery" fullname="Brian P. Flannery">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="1992"/>
          </front>
          <seriesInfo name="ISBN" value="0-521-43108-5"/>
          <refcontent>2nd Ed., Cambridge University Press</refcontent>
        </reference>
        <reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2104" quoteTitle="true" derivedAnchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t indent="0">This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2104"/>
          <seriesInfo name="DOI" value="10.17487/RFC2104"/>
        </reference>
        <reference anchor="RFC3971" target="https://www.rfc-editor.org/info/rfc3971" quoteTitle="true" derivedAnchor="RFC3971">
          <front>
            <title>SEcure Neighbor Discovery (SEND)</title>
            <author fullname="J. Arkko" initials="J." role="editor" surname="Arkko"/>
            <author fullname="J. Kempf" initials="J." surname="Kempf"/>
            <author fullname="B. Zill" initials="B." surname="Zill"/>
            <author fullname="P. Nikander" initials="P." surname="Nikander"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3971"/>
          <seriesInfo name="DOI" value="10.17487/RFC3971"/>
        </reference>
        <reference anchor="RFC4953" target="https://www.rfc-editor.org/info/rfc4953" quoteTitle="true" derivedAnchor="RFC4953">
          <front>
            <title>Defending TCP Against Spoofing Attacks</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <date month="July" year="2007"/>
            <abstract>
              <t indent="0">Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4953"/>
          <seriesInfo name="DOI" value="10.17487/RFC4953"/>
        </reference>
        <reference anchor="RFC4963" target="https://www.rfc-editor.org/info/rfc4963" quoteTitle="true" derivedAnchor="RFC4963">
          <front>
            <title>IPv4 Reassembly Errors at High Data Rates</title>
            <author fullname="J. Heffner" initials="J." surname="Heffner"/>
            <author fullname="M. Mathis" initials="M." surname="Mathis"/>
            <author fullname="B. Chandler" initials="B." surname="Chandler"/>
            <date month="July" year="2007"/>
            <abstract>
              <t indent="0">IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4963"/>
          <seriesInfo name="DOI" value="10.17487/RFC4963"/>
        </reference>
        <reference anchor="RFC5927" target="https://www.rfc-editor.org/info/rfc5927" quoteTitle="true" derivedAnchor="RFC5927">
          <front>
            <title>ICMP Attacks against TCP</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="July" year="2010"/>
            <abstract>
              <t indent="0">This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5927"/>
          <seriesInfo name="DOI" value="10.17487/RFC5927"/>
        </reference>
        <reference anchor="RFC6194" target="https://www.rfc-editor.org/info/rfc6194" quoteTitle="true" derivedAnchor="RFC6194">
          <front>
            <title>Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms</title>
            <author fullname="T. Polk" initials="T." surname="Polk"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="March" year="2011"/>
            <abstract>
              <t indent="0">This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6194"/>
          <seriesInfo name="DOI" value="10.17487/RFC6194"/>
        </reference>
        <reference anchor="RFC6274" target="https://www.rfc-editor.org/info/rfc6274" quoteTitle="true" derivedAnchor="RFC6274">
          <front>
            <title>Security Assessment of the Internet Protocol Version 4</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6274"/>
          <seriesInfo name="DOI" value="10.17487/RFC6274"/>
        </reference>
        <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973" quoteTitle="true" derivedAnchor="RFC6973">
          <front>
            <title>Privacy Considerations for Internet Protocols</title>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="J. Morris" initials="J." surname="Morris"/>
            <author fullname="M. Hansen" initials="M." surname="Hansen"/>
            <author fullname="R. Smith" initials="R." surname="Smith"/>
            <date month="July" year="2013"/>
            <abstract>
              <t indent="0">This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6973"/>
          <seriesInfo name="DOI" value="10.17487/RFC6973"/>
        </reference>
        <reference anchor="RFC6980" target="https://www.rfc-editor.org/info/rfc6980" quoteTitle="true" derivedAnchor="RFC6980">
          <front>
            <title>Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="August" year="2013"/>
            <abstract>
              <t indent="0">This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6980"/>
          <seriesInfo name="DOI" value="10.17487/RFC6980"/>
        </reference>
        <reference anchor="RFC7098" target="https://www.rfc-editor.org/info/rfc7098" quoteTitle="true" derivedAnchor="RFC7098">
          <front>
            <title>Using the IPv6 Flow Label for Load Balancing in Server Farms</title>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <author fullname="W. Tarreau" initials="W." surname="Tarreau"/>
            <date month="January" year="2014"/>
            <abstract>
              <t indent="0">This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7098"/>
          <seriesInfo name="DOI" value="10.17487/RFC7098"/>
        </reference>
        <reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258" quoteTitle="true" derivedAnchor="RFC7258">
          <front>
            <title>Pervasive Monitoring Is an Attack</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="188"/>
          <seriesInfo name="RFC" value="7258"/>
          <seriesInfo name="DOI" value="10.17487/RFC7258"/>
        </reference>
        <reference anchor="RFC7707" target="https://www.rfc-editor.org/info/rfc7707" quoteTitle="true" derivedAnchor="RFC7707">
          <front>
            <title>Network Reconnaissance in IPv6 Networks</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="T. Chown" initials="T." surname="Chown"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7707"/>
          <seriesInfo name="DOI" value="10.17487/RFC7707"/>
        </reference>
        <reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc7721" quoteTitle="true" derivedAnchor="RFC7721">
          <front>
            <title>Security and Privacy Considerations for IPv6 Address Generation Mechanisms</title>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7721"/>
          <seriesInfo name="DOI" value="10.17487/RFC7721"/>
        </reference>
        <reference anchor="RFC7739" target="https://www.rfc-editor.org/info/rfc7739" quoteTitle="true" derivedAnchor="RFC7739">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="February" year="2016"/>
            <abstract>
              <t indent="0">IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7739"/>
          <seriesInfo name="DOI" value="10.17487/RFC7739"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8937" target="https://www.rfc-editor.org/info/rfc8937" quoteTitle="true" derivedAnchor="RFC8937">
          <front>
            <title>Randomness Improvements for Security Protocols</title>
            <author fullname="C. Cremers" initials="C." surname="Cremers"/>
            <author fullname="L. Garratt" initials="L." surname="Garratt"/>
            <author fullname="S. Smyshlyaev" initials="S." surname="Smyshlyaev"/>
            <author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="October" year="2020"/>
            <abstract>
              <t indent="0">Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.</t>
              <t indent="0">This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8937"/>
          <seriesInfo name="DOI" value="10.17487/RFC8937"/>
        </reference>
        <reference anchor="RFC9414" target="https://www.rfc-editor.org/info/rfc9414" quoteTitle="true" derivedAnchor="RFC9414">
          <front>
            <title>Unfortunate History of Transient Numeric Identifiers</title>
            <author initials="F" surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="July"/>
          </front>
          <seriesInfo name="RFC" value="9414"/>
          <seriesInfo name="DOI" value="10.17487/RFC9414"/>
        </reference>
        <reference anchor="RFC9416" target="https://www.rfc-editor.org/info/rfc9416" quoteTitle="true" derivedAnchor="RFC9416">
          <front>
            <title>Security Considerations for Transient Numeric Identifiers Employed in Network Protocols</title>
            <author initials="F" surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="July"/>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="9416"/>
          <seriesInfo name="DOI" value="10.17487/RFC9416"/>
        </reference>
        <reference anchor="Romailler2020" target="https://research.kudelskisecurity.com/2020/07/28/the-definitive-guide-to-modulo-bias-and-how-to-avoid-it/" quoteTitle="true" derivedAnchor="Romailler2020">
          <front>
            <title>The Definitive Guide to "Modulo Bias and How to Avoid It"!</title>
            <author initials="Y." surname="Romailler" fullname="Yolan Romailler">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" year="2020"/>
          </front>
          <refcontent>Kudelski Security Research</refcontent>
        </reference>
        <reference anchor="Sanfilippo1998a" target="http://seclists.org/bugtraq/1998/Dec/48" quoteTitle="true" derivedAnchor="Sanfilippo1998a">
          <front>
            <title>about the ip header id</title>
            <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfilippo">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="1998"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Sanfilippo1998b" target="https://seclists.org/bugtraq/1998/Dec/79" quoteTitle="true" derivedAnchor="Sanfilippo1998b">
          <front>
            <title>new tcp scan method</title>
            <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfilippo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1998" month="December" day="18"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Sanfilippo1999" target="https://github.com/antirez/hping/raw/master/docs/MORE-FUN-WITH-IPID" quoteTitle="true" derivedAnchor="Sanfilippo1999">
          <front>
            <title>more ip id</title>
            <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfilippo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="November"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf" quoteTitle="true" derivedAnchor="Schuba1993">
          <front>
            <title>Addressing Weakness in the Domain Name System Protocol</title>
            <author initials="C." surname="Schuba" fullname="Christoph Schuba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1993" month="August"/>
          </front>
        </reference>
        <reference anchor="Shimomura1995" target="https://www.gont.com.ar/files/post-shimomura-usenet.txt" quoteTitle="true" derivedAnchor="Shimomura1995">
          <front>
            <title>Technical details of the attack described by Markoff in NYT</title>
            <author initials="T." surname="Shimomura" fullname="Tsutomu Shimomura">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="25" year="1995" month="January"/>
          </front>
          <refcontent>message to the USENET comp.security.misc newsgroup</refcontent>
        </reference>
        <reference anchor="Silbersack2005" target="https://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf" quoteTitle="true" derivedAnchor="Silbersack2005">
          <front>
            <title>Improving TCP/IP security through randomization without sacrificing interoperability</title>
            <author initials="M." surname="Silbersack" fullname="Michael James Silbersack">
              <organization showOnFrontPage="true">The FreeBSD Project</organization>
            </author>
          </front>
          <refcontent>EuroBSDCon 2005 Conference</refcontent>
        </reference>
        <reference anchor="SipHash" target="https://github.com/veorq/SipHash" quoteTitle="true" derivedAnchor="SipHash">
          <front>
            <title>SipHash: a fast short-input PRF</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="February"/>
          </front>
        </reference>
        <reference anchor="TBIT" target="https://www.icir.org/tbit/" quoteTitle="true" derivedAnchor="TBIT">
          <front>
            <title>TBIT, the TCP Behavior Inference Tool</title>
            <author>
              <organization showOnFrontPage="true">TBIT</organization>
            </author>
            <date year="2001"/>
          </front>
        </reference>
        <reference anchor="TCPT-uptime" target="https://seclists.org/bugtraq/2001/Mar/182" quoteTitle="true" derivedAnchor="TCPT-uptime">
          <front>
            <title>TCP Timestamping - Obtaining System Uptime Remotely</title>
            <author initials="B." surname="McDanel" fullname="Bret McDanel">
              <organization showOnFrontPage="true">Securiteam</organization>
            </author>
            <date month="March" year="2001"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Zalewski2001" target="https://lcamtuf.coredump.cx/oldtcp/tcpseq.html" quoteTitle="true" derivedAnchor="Zalewski2001">
          <front>
            <title>Strange Attractors and TCP/IP Sequence Number Analysis</title>
            <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="April"/>
          </front>
        </reference>
        <reference anchor="Zalewski2002" target="https://lcamtuf.coredump.cx/newtcp/" quoteTitle="true" derivedAnchor="Zalewski2002">
          <front>
            <title>Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later (2002)</title>
            <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
        <reference anchor="Zalewski2012" target="https://lcamtuf.coredump.cx/p0f.shtml" quoteTitle="true" derivedAnchor="Zalewski2012">
          <front>
            <title>p0f v3 (3.09b)</title>
            <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="fawed-algorithms" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-algorithms-and-techniques-w">Algorithms and Techniques with Known Issues</name>
      <t indent="0" pn="section-appendix.a-1">The following subsections discuss algorithms and techniques with known negative security and privacy implications.

</t>
      <aside pn="section-appendix.a-2">
        <t indent="0" pn="section-appendix.a-2.1">NOTE: As discussed in <xref target="intro" format="default" sectionFormat="of" derivedContent="Section 1"/>, the use of cryptographic techniques might allow for the safe use of some of these algorithms and techniques. However, this should be evaluated on a case-by-case basis.
</t>
      </aside>
      <section anchor="trad_selection" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.1">
        <name slugifiedName="name-predictable-linear-identifi">Predictable Linear Identifiers Algorithm</name>
        <t indent="0" pn="section-appendix.a.1-1">One of the most trivial ways to achieve uniqueness with a low identifier reuse frequency is to produce a linear sequence. This type of algorithm has been employed in the past to generate identifiers of Categories #1, #2, and #4 (please see <xref target="categorizing" format="default" sectionFormat="of" derivedContent="Section 6"/> for an analysis of these categories). 
        </t>
        <t indent="0" pn="section-appendix.a.1-2">
For example, the following algorithm has been employed (see, e.g., <xref target="Morris1985" format="default" sectionFormat="of" derivedContent="Morris1985"/>, <xref target="Shimomura1995" format="default" sectionFormat="of" derivedContent="Shimomura1995"/>, <xref target="Silbersack2005" format="default" sectionFormat="of" derivedContent="Silbersack2005"/>, and <xref target="CPNI-TCP" format="default" sectionFormat="of" derivedContent="CPNI-TCP"/>) in a number of operating systems for selecting IP IDs, TCP ephemeral port numbers, etc.:</t>
        <sourcecode type="c" markers="false" pn="section-appendix.a.1-3">
    /* Initialization code */

    next_id = min_id;
    id_inc= 1;


    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;

    do {
        if (next_id == max_id) {
            next_id = min_id;
        }
        else {
            next_id = next_id + id_inc;
        }

        if (suitable_id(next_id)) {
            return next_id;
        }

        retry--;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
        <t indent="0" pn="section-appendix.a.1-4">NOTE:</t>
        <t indent="3" pn="section-appendix.a.1-5">suitable_id() checks whether a candidate numeric identifier is suitable (e.g., whether it is unique or not).
</t>
        <t indent="0" pn="section-appendix.a.1-6">For obvious reasons, this algorithm results in predictable sequences. Since a global counter is used to generate the transient numeric identifiers ("next_id" in the example above), an entity that learns one numeric identifier can infer past numeric identifiers and predict future values to be generated by the same algorithm. Since the value employed for the increments is known (such as "1" in this case), an attacker can sample two values and learn the number of identifiers that were generated in between the two sampled values. Furthermore, if the counter is initialized, to some known value (e.g., when the system is bootstrapped), the algorithm will leak additional information, such as the number of transmitted fragmented datagrams in the case of an IP ID generator <xref target="Sanfilippo1998a" format="default" sectionFormat="of" derivedContent="Sanfilippo1998a"/> or the system uptime in the case of TCP timestamps <xref target="TCPT-uptime" format="default" sectionFormat="of" derivedContent="TCPT-uptime"/>.
</t>
      </section>
      <section anchor="random-increments" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.2">
        <name slugifiedName="name-random-increments-algorithm">Random-Increments Algorithm</name>
        <t indent="0" pn="section-appendix.a.2-1">This algorithm offers a middle ground between the algorithms that
  generate randomized transient numeric identifiers (such as those described in Sections <xref target="simple-randomization" format="counter" sectionFormat="of" derivedContent="7.1.1"/> and <xref target="simple-randomization2" format="counter" sectionFormat="of" derivedContent="7.1.2"/>) and those that generate identifiers with a predictable monotonically increasing function (see <xref target="trad_selection" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>). 
</t>
        <sourcecode type="c" markers="false" pn="section-appendix.a.2-2">
    /* Initialization code */

    next_id = random();        /* Initialization value */
    id_rinc = 500;             /* Determines the trade-off */


    /* Transient Numeric ID selection function */

    id_range = max_id - min_id + 1;
    retry = id_range;


    do {
        /* Random increment */
        id_inc = (random() % id_rinc) + 1;

        if ( (max_id - next_id) &gt;= id_inc){
            next_id = next_id + id_inc;
        }
        else {
            next_id = min_id + id_inc - (max_id - next_id);
        }

        if (suitable_id(next_id)) {
           return next_id;
        }

        retry = retry - id_inc;

    } while (retry &gt; 0);

    return ERROR;
</sourcecode>
        <t indent="0" pn="section-appendix.a.2-3">NOTE:</t>
        <t indent="3" pn="section-appendix.a.2-4">random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique <xref target="Romailler2020" format="default" sectionFormat="of" derivedContent="Romailler2020"/> can be used.</t>
        <t indent="3" pn="section-appendix.a.2-5">suitable_id() is a function that checks whether a candidate identifier is suitable (e.g., whether it is unique or not).
</t>
        <t indent="0" pn="section-appendix.a.2-6">
This algorithm aims at producing a global monotonically increasing sequence of transient numeric identifiers while avoiding the
use of fixed increments, which would lead to trivially predictable sequences.  The value "id_rinc" allows for direct control of the trade-off between unpredictability and identifier reuse frequency. The smaller the value of "id_rinc", the more similar this algorithm is to a predicable, global linear identifier generation algorithm (as the one in <xref target="trad_selection" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>). The larger the value of "id_rinc", the more similar this algorithm is to the algorithm described in <xref target="simple-randomization" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/> of this document.</t>
        <t indent="0" pn="section-appendix.a.2-7">
When the identifiers wrap, there is a risk of collisions of transient numeric identifiers (i.e., identifier reuse). Therefore, "id_rinc" should be selected according to the following criteria:
</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-8">
          <li pn="section-appendix.a.2-8.1">It should maximize the wrapping time of the identifier space.</li>
          <li pn="section-appendix.a.2-8.2">It should minimize identifier reuse frequency.</li>
          <li pn="section-appendix.a.2-8.3">It should maximize unpredictability.</li>
        </ul>
        <t indent="0" pn="section-appendix.a.2-9">
Clearly, these are competing goals, and the decision of which value of "id_rinc" to use is a trade-off. Therefore, the value of "id_rinc" is at times a configurable parameter so that system administrators can make the trade-off for themselves. We note that the alternative algorithms discussed throughout this document offer better interoperability, security, and privacy properties than this algorithm, and hence, implementation of this algorithm is discouraged.
</t>
      </section>
      <section anchor="reuse-across-context" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.3">
        <name slugifiedName="name-reusing-identifiers-across-">Reusing Identifiers Across Different Contexts</name>
        <t indent="0" pn="section-appendix.a.3-1">Employing the same identifier across contexts in which stability is not required (i.e., overloading the semantics of transient numeric identifiers) usually has negative security and privacy implications.</t>
        <t indent="0" pn="section-appendix.a.3-2">For example, in order to generate transient numeric identifiers of Category #2 or #3, an implementation or specification might be tempted to employ a source for the numeric identifiers that is known to provide unique values but that may also be predictable or leak information related to the entity generating the identifier. This technique has been employed in the past for, e.g., generating IPv6 IIDs by reusing the MAC address of the underlying network interface card. However, as noted in <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/> and <xref target="RFC7707" format="default" sectionFormat="of" derivedContent="RFC7707"/>, embedding link-layer addresses in IPv6 IIDs not only results in predictable values but also leaks information about the manufacturer of the underlying network interface card, allows for network activity correlation, and makes address-based scanning attacks feasible.
</t>
      </section>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">The authors would like to thank (in alphabetical order) <contact fullname="Bernard Aboba"/>, <contact fullname="Jean-Philippe Aumasson"/>, <contact fullname="Steven Bellovin"/>, <contact fullname="Luis León Cárdenas Graide"/>, <contact fullname="Spencer Dawkins"/>, <contact fullname="Theo de Raadt"/>, <contact fullname="Guillermo Gont"/>, <contact fullname="Joseph Lorenzo Hall"/>, <contact fullname="Gre Norcie"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Vincent Roca"/>, <contact fullname="Shivan Sahib"/>, <contact fullname="Rich Salz"/>, <contact fullname="Martin Thomson"/>, and <contact fullname="Michael Tüxen"/> for providing valuable comments on earlier draft versions of this document.</t>
      <t indent="0" pn="section-appendix.b-2">The authors would like to thank <contact fullname="Shivan Sahib"/> and <contact fullname="Christopher Wood"/> for their guidance during the publication process of this document.</t>
      <t indent="0" pn="section-appendix.b-3">The authors would like to thank <contact fullname="Jean-Philippe Aumasson"/> and <contact fullname="Mathew D. Green"/> (John Hopkins University) for kindly answering a number of questions.</t>
      <t indent="0" pn="section-appendix.b-4">The authors would like to thank <contact fullname="Diego Armando Maradona"/> for his magic and inspiration.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Fernando Gont" initials="F." surname="Gont">
        <organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</organization>
        <address>
          <postal>
            <street>Segurola y Habana 4310 7mo piso</street>
            <city>Ciudad Autonoma de Buenos Aires</city>
            <country>Argentina</country>
          </postal>
          <email>fgont@si6networks.com</email>
          <uri>https://www.si6networks.com</uri>
        </address>
      </author>
      <author fullname="Ivan Arce" initials="I." surname="Arce">
        <organization abbrev="Quarkslab" showOnFrontPage="true">Quarkslab</organization>
        <address>
          <postal>
            <street>Segurola y Habana 4310 7mo piso</street>
            <city>Ciudad Autonoma de Buenos Aires</city>
            <country>Argentina</country>
          </postal>
          <email>iarce@quarkslab.com</email>
          <uri>https://www.quarkslab.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
