<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="bcp" consensus="true" docName="draft-gont-numeric-ids-sec-considerations-11" number="9416" ipr="trust200902" updates="3552" obsoletes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2023-07-21T17:39:32" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-gont-numeric-ids-sec-considerations-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9416" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Security Considerations for IDs">Security Considerations for Transient Numeric Identifiers Employed in Network Protocols</title>
    <seriesInfo name="RFC" value="9416" stream="IETF"/>
    <seriesInfo name="BCP" value="72" stream="IETF"/>
    <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"/>
    <area>sec</area>
    <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">
Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations.
      </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 memo documents an Internet Best Current Practice.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in 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/rfc9416" 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. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </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-issues-with-the-specificati">Issues with the Specification of Transient Numeric Identifiers</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-common-flaws-in-the-generat">Common Flaws in the Generation 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-requirements-for-transient-">Requirements for Transient Numeric Identifiers</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-iana-considerations">IANA Considerations</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-security-considerations">Security Considerations</xref></t>
          </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-references">References</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-normative-references">Normative References</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-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><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 <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/>.</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 for confidentiality and authentication might not eliminate all the issues associated with predictable transient numeric identifiers. Therefore, due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed. 
      </t>
      <aside pn="section-1-8">
        <t indent="0" pn="section-1-8.1">NOTE: For example, cryptographic authentication can readily mitigate data injection attacks even in the presence of predictable transient numeric identifiers (such as "sequence numbers"). However, use of flawed algorithms (such as global counters) for generating transient numeric identifiers could still result in information leakages even when cryptographic techniques are employed. These information leakages could in turn be leveraged to perform other devastating attacks (please see <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/> for further details).
        </t>
      </aside>
      <t indent="0" pn="section-1-9"><xref target="issues" format="default" sectionFormat="of" derivedContent="Section 3"/> provides an overview of common flaws in the specification of transient numeric identifiers. <xref target="vulns" format="default" sectionFormat="of" derivedContent="Section 4"/> provides an overview of common flaws in the generation of transient numeric identifiers and their associated security and privacy implications. Finally, <xref target="reqs" format="default" sectionFormat="of" derivedContent="Section 5"/> provides key guidelines for protocol designers.
</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 (e.g., see <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" and "hard".
	</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 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 recovered.
</dd>
      </dl>
      <t indent="0" pn="section-2-2">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.
</t>
    </section>
    <section anchor="issues" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-issues-with-the-specificati">Issues with the Specification of Transient Numeric Identifiers</name>
      <t indent="0" pn="section-3-1">Recent work on transient numeric identifier usage in protocol specifications and implementations <xref target="RFC9414" format="default" sectionFormat="of" derivedContent="RFC9414"/> <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/> revealed 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-3-2">
        <li pn="section-3-2.1">protocol specifications that under specify their transient numeric identifiers</li>
        <li pn="section-3-2.2">protocol specifications that over specify their transient numeric identifiers</li>
        <li pn="section-3-2.3">protocol implementations that simply fail to comply with the specified requirements</li>
      </ul>
      <t indent="0" pn="section-3-3">Both under specifying and over specifying transient numeric identifiers is
   hazardous. TCP local ports <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/>, as well as DNS IDs
   <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>, were originally under specified, leading to implementations that resulted in
   predictable values and thus were vulnerable to numerous off-path
   attacks. Over specification, as for IPv6 Interface Identifiers (IIDs)
   <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> and IPv6 Identification values <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/>, left
   implementations unable to respond to security and privacy issues
   stemming from the mandated or recommended algorithms -- IPv6 IIDs need not expose
   privacy-sensitive link-layer addresses, and predictable IPv6 Fragment Header
   Identification values invite the same off-path attacks that plague TCP.</t>
      <t indent="0" pn="section-3-4">Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. That is, appropriate guidance is provided by the protocol specification (whether it be the core specification or an update to it), but an implementation simply fails to follow such guidance. For example, some popular operating systems still fail to implement transport-protocol port randomization, as specified in <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>.</t>
      <t indent="0" pn="section-3-5">Clear specification of the interoperability requirements for the transient numeric identifiers will help identify possible algorithms that could be employed to generate them and also make evident if such identifiers are being over specified. A protocol specification will usually also benefit from a vulnerability assessment of the transient numeric identifiers they specify to prevent the corresponding considerations from being overlooked. 
</t>
    </section>
    <section anchor="vulns" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-common-flaws-in-the-generat">Common Flaws in the Generation of Transient Numeric Identifiers</name>
      <t indent="0" pn="section-4-1">This section briefly notes common flaws associated with the generation of transient numeric identifiers. Such common flaws include, but are not limited to:
</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">employing trivial algorithms (e.g., global counters) that result in predictable identifiers,</li>
        <li pn="section-4-2.2">employing the same identifier across contexts in which constancy is not required,</li>
        <li pn="section-4-2.3">reusing identifiers across different protocols or layers of the protocol stack,</li>
        <li pn="section-4-2.4">initializing counters or timers to constant values when such initialization is not required,</li>
        <li pn="section-4-2.5">employing the same increment space across different contexts, and</li>
        <li pn="section-4-2.6">use of flawed Pseudorandom Number Generators (PRNGs).</li>
      </ul>
      <t indent="0" pn="section-4-3">
   Employing trivial algorithms for generating the identifiers means
   that any node that is able to sample such identifiers can easily
   predict future identifiers employed by the victim node.</t>
      <t indent="0" pn="section-4-4">
   When one identifier is employed across contexts where such constancy
   is not needed, activity correlation is made possible.  For
   example, employing an identifier that is constant across networks
   allows for node tracking across networks.
</t>
      <t indent="0" pn="section-4-5">
   Reusing identifiers across different layers or protocols ties the
   security and privacy properties of the protocol reusing the identifier to the
   security and privacy properties of the original identifier (over
   which the protocol reusing the identifier may have no control
   regarding its generation).  Besides, when reusing an identifier
   across protocols from different layers, the goal of isolating the
   properties of a layer from those of another layer is broken, and the
   vulnerability assessment may be harder to perform since the
   combined system, rather than each protocol in isolation, will have to
   be assessed.
</t>
      <t indent="0" pn="section-4-6">
   At times, a protocol needs to convey order information (whether it be
   sequence, timing, etc.).  In many cases, there is no reason for the
   corresponding counter or timer to be initialized to any specific
   value, e.g., at system bootstrap. Similarly, there may not be a need for the difference between successive counter
values to be predictable.
      </t>
      <t indent="0" pn="section-4-7">
   A node that implements a per-context linear function may share the
   increment space among different contexts (please see the "Simple PRF-Based Algorithm" section in <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/>).
   Sharing the same increment space allows an attacker that can sample
   identifiers in other context to, e.g., learn how many identifiers have
   been generated between two sampled values.
      </t>
      <t indent="0" pn="section-4-8">Finally, some implementations have been found to employ flawed PRNGs (e.g., see <xref target="Klein2007" format="default" sectionFormat="of" derivedContent="Klein2007"/>).</t>
    </section>
    <section anchor="reqs" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-requirements-for-transient-">Requirements for Transient Numeric Identifiers</name>
      <t indent="0" pn="section-5-1">Protocol specifications that employ transient numeric identifiers <bcp14>MUST</bcp14> explicitly specify the interoperability requirements for the aforementioned transient numeric identifiers (e.g., required properties such as uniqueness, along with the failure severity if such requirements are not met).
</t>
      <t indent="0" pn="section-5-2">A vulnerability assessment of the aforementioned transient numeric identifiers <bcp14>MUST</bcp14> be performed as part of the specification process. 
Such vulnerability assessment should cover, at least, spoofing, tampering, repudiation, information disclosure, DoS, and
elevation of privilege. 
</t>
      <aside pn="section-5-3">
        <t indent="0" pn="section-5-3.1">NOTE: Sections <xref target="RFC9415" section="8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9415#section-8" derivedContent="RFC9415"/> and <xref target="RFC9415" section="9" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9415#section-9" derivedContent="RFC9415"/> of <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/> provide a general vulnerability assessment of transient numeric identifiers, along with a vulnerability assessment of common algorithms for generating transient numeric identifiers. Please see <xref target="Shostack2014" format="default" sectionFormat="of" derivedContent="Shostack2014"/> for further guidance on threat modeling.
</t>
      </aside>
      <t indent="0" pn="section-5-4">Protocol specifications <bcp14>SHOULD NOT</bcp14> employ predictable transient numeric identifiers, except when such predictability is the result of their interoperability requirements.
</t>
      <t indent="0" pn="section-5-5">Protocol specifications that employ transient numeric identifiers
   <bcp14>SHOULD</bcp14> recommend an algorithm for generating the aforementioned
   transient numeric identifiers that mitigates the vulnerabilities
   identified in the previous step, such as those discussed in
   <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/>.</t>
      <t indent="0" pn="section-5-6">
   As discussed in <xref target="intro" format="default" sectionFormat="of" derivedContent="Section 1"/>, use of cryptographic techniques for
   confidentiality and authentication might not eliminate all the
   issues associated with predictable transient numeric identifiers.
   Therefore, the advice from this section <bcp14>MUST</bcp14> still be applied
   for cases where cryptographic techniques for
   confidentiality or authentication are employed. 
</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This entire document is about the security and privacy implications of transient numeric identifiers and formally updates <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/> such that the security and privacy implications of transient numeric identifiers are addressed when writing the "Security Considerations" section of future RFCs.
</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.gont-predictable-numeric-ids" to="PREDICTABLE-NUMERIC-IDS"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. 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="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <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="S. 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="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="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">Trusteer</organization>
            </author>
            <date year="2007" month="October"/>
          </front>
        </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 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="I-D.gont-predictable-numeric-ids" target="https://datatracker.ietf.org/doc/html/draft-gont-predictable-numeric-ids-03" quoteTitle="true" derivedAnchor="PREDICTABLE-NUMERIC-IDS">
          <front>
            <title>Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont">
         </author>
            <author initials="I." surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true">Quarkslab</organization>
            </author>
            <date month="March" day="11" year="2019"/>
            <abstract>
              <t indent="0">   This document performs an analysis of the security and privacy
   implications of different types of "numeric identifiers" used in IETF
   protocols, and tries to categorize them based on their
   interoperability requirements and the associated failure severity
   when such requirements are not met.  It describes a number of
   algorithms that have been employed in real implementations to meet
   such requirements and analyzes their security and privacy properties.
   Additionally, it provides advice on possible algorithms that could be
   employed to satisfy the interoperability requirements of each
   identifier type, while minimizing the security and privacy
   implications, thus providing guidance to protocol designers and
   protocol implementers.  Finally, it provides recommendations for
   future protocol specifications regarding the specification of the
   aforementioned numeric identifiers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-predictable-numeric-ids-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <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="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="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="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="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="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="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="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="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="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="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="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>
        <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="RFC9415" target="https://www.rfc-editor.org/info/rfc9415" quoteTitle="true" derivedAnchor="RFC9415">
          <front>
            <title>On the Generation 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="9415"/>
          <seriesInfo name="DOI" value="10.17487/RFC9415"/>
        </reference>
        <reference anchor="Sanfilippo1998a" target="https://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="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="Shostack2014" quoteTitle="true" derivedAnchor="Shostack2014">
          <front>
            <title>Threat Modeling: Designing for Security</title>
            <author initials="A." surname="Shostack" fullname="Adam Shostack">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="February"/>
          </front>
          <refcontent>Wiley, 1st edition</refcontent>
        </reference>
        <reference anchor="Silbersack2005" target="http://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>
            <date year="2005" month="January"/>
          </front>
          <refcontent>EuroBSDCon 2005 Conference</refcontent>
        </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>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank (in alphabetical order) <contact fullname="Bernard Aboba"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Theo de Raadt"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Russ Housley"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Charlie Kaufman"/>, <contact fullname="Erik Kline"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Joe Touch"/>, <contact fullname="Michael Tüxen"/>, <contact fullname="Robert Wilton"/>, and <contact fullname="Paul Wouters"/> for providing valuable comments on draft versions of this document.</t>
      <t indent="0" pn="section-appendix.a-2">The authors would like to thank (in alphabetical order) <contact fullname="Steven Bellovin"/>, <contact fullname="Joseph Lorenzo Hall"/>, and <contact fullname="Gre Norcie"/> for providing valuable comments on <xref target="I-D.gont-predictable-numeric-ids" format="default" sectionFormat="of" derivedContent="PREDICTABLE-NUMERIC-IDS"/>, on which the present document is based.</t>
      <t indent="0" pn="section-appendix.a-3">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.b">
      <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>
