<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="no" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="bcp" consensus="true" docName="draft-gont-numeric-ids-sec-considerations-11" number="9416" ipr="trust200902" updates="3552"> updates="3552" obsoletes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="Security Considerations for IDs">Security Considerations for Transient Numeric Identifiers Employed in Network Protocols</title>
    <seriesInfo name="RFC" value="9416"/>
    <seriesInfo name="BCP" value="72"/>
    <author fullname="Fernando Gont" initials="F." surname="Gont">
      <organization abbrev="SI6 Networks">SI6 Networks</organization>
      <address>
        <postal>
          <street>Segurola y Habana 4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <region>Buenos Aires</region>
          <country>Argentina</country>
        </postal>

<!--       <phone>+54 11 4650 8472</phone> -->
        <email>fgont@si6networks.com</email>
        <uri>https://www.si6networks.com</uri>
      </address>
    </author>
    <author fullname="Ivan Arce" initials="I." surname="Arce">
      <organization abbrev="Quarkslab">Quarkslab</organization>
      <address>
        <postal>
          <street>Segurola y Habana 4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <region>Buenos Aires</region>
          <country>Argentina</country>
        </postal>
        <email>iarce@quarkslab.com</email>
        <uri>https://www.quarkslab.com</uri>
      </address>
    </author>

<date/>
<!--
<area>Internet</area>
<workgroup>Dynamic Host Configuration (dhc)</workgroup>
-->
<!-- <area/> -->
<!-- <workgroup/> -->
    <date year="2023" month="July"/>
    <area>sec</area>
<keyword>security</keyword>
<keyword>vulnerability</keyword>
<keyword>algorithm</keyword>
<keyword>attack</keyword>
<keyword>fingerprinting</keyword>
    <abstract>
      <t>
Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) to or data injection and to information leakage leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="intro"> anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
Network
Networking protocols employ a variety of transient numeric identifiers for different protocol entities, ranging from DNS Transaction IDs (TxIDs) to transport protocol numbers (e.g. TCP ports) or objects, such as IPv4 and IPv6 Identification values <xref target="RFC0791" format="default"/> <xref target="RFC8200" format="default"/>, IPv6 Interface Identifiers (IIDs). (IIDs) <xref target="RFC4291" format="default"/>, transport-protocol ephemeral port numbers <xref target="RFC6056" format="default"/>, TCP Initial Sequence Numbers (ISNs) <xref target="RFC9293" format="default"/>, NTP Reference IDs (REFIDs) <xref target="RFC5905" format="default"/>, and DNS IDs <xref target="RFC1035" format="default"/>. These identifiers usually typically have specific properties requirements (e.g., uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications (e.g., uniqueness during a specified period of time), implications, and an associated failure severity when such properties requirements are not met.
</t>

<t>The TCP/IP protocol suite alone has met <xref target="RFC9415" format="default"/>.</t>
<aside>
<t>NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".</t>
</aside>

<t>For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks on its transient numeric identifiers over the past 30 years or more, attacks, with effects ranging from Denial of Service (DoS) or data injection, injection to information leakage leakages that could be exploited for pervasive monitoring <xref target="RFC7258"/>. target="RFC7258" format="default"/>. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications. While it is generally trivial to identify an algorithm that can satisfy the interoperability requirements for of a given transient numeric identifier, there exists practical empirical evidence <xref target="I-D.irtf-pearg-numeric-ids-history"/> exists that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is prone to error.</t> error <xref target="RFC9414" format="default"/>.</t>
      <t>For example, implementations have been subject to security and/or privacy issues resulting from:

<list style="symbols">
<t>Predictable TCP sequence numbers (see e.g. from:</t>
      <ul spacing="normal">
        <li>predictable IPv4 or IPv6 Identification values (e.g., see <xref target="Morris1985"/>, target="Sanfilippo1998a" format="default"/>, <xref target="Bellovin1989"/>, target="RFC6274" format="default"/>, and <xref target="RFC6528"/>)</t>
<t>Predictable transport protocol target="RFC7739" format="default"/>),</li>
        <li>predictable IPv6 IIDs (e.g., see <xref target="RFC7217" format="default"/>, <xref target="RFC7707" format="default"/>, and <xref target="RFC7721" format="default"/>),</li>
        <li>predictable transport-protocol ephemeral port numbers (see e.g. (e.g., see <xref target="Silbersack2005"/> target="RFC6056" format="default"/> and <xref target="RFC6056"/>)</t>
<t>Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. target="Silbersack2005" format="default"/>),</li>
        <li>predictable TCP Initial Sequence Numbers (ISNs) (e.g., see <xref target="Sanfilippo1998a"/>, target="Morris1985" format="default"/>, <xref target="RFC6274"/>, target="Bellovin1989" format="default"/>, and <xref target="RFC7739"/>)</t>
<t>Predictable IPv6 IIDs (see e.g. <xref target="RFC7217"/>, target="RFC6528" format="default"/>),</li>
        <li>predictable initial timestamps in TCP timestamps options (e.g., see <xref target="RFC7707"/>, target="TCPT-uptime" format="default"/> and <xref target="RFC7721"/>)</t>
<t>Predictable target="RFC7323" format="default"/>), and</li>
        <li>predictable DNS TxIDs (see e.g. IDs (see, e.g., <xref target="Schuba1993"/> target="Schuba1993" format="default"/> and <xref target="Klein2007"/>)</t>
</list> target="Klein2007" format="default"/>).</li>
      </ul>

      <t>

Recent history indicates that that, when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked overlooked, and inappropriate algorithms to generate such identifiers are either suggested in the specification specifications or selected by implementers. As a result, advice in this area is warranted.
</t>
      <t>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.
<list style="hanging">
<t hangText="Note:">
<vspace blankLines="0" />For
      </t>
        <aside><t>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="I-D.irtf-pearg-numeric-ids-generation"/> target="RFC9415" format="default"/> for further details).
</t>
</list>
</t>
	</t></aside>
      <t><xref target="issues"/> target="issues" format="default"/> provides an overview of common flaws in the specification of transient numeric identifiers. <xref target="vulns"/> target="vulns" format="default"/> provides an overview of common flaws in the implications generation of predictable transient numeric identifiers. identifiers and their associated security and privacy implications. Finally, <xref target="reqs"/> target="reqs" format="default"/> provides key guidelines for protocol designers.
</t>
    </section>
    <section title="Terminology" anchor="terminology">
<t>
<list style="hanging">
<t hangText="Transient anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <dl newline="true" spacing="normal">
        <dt>Transient Numeric Identifier:">
<vspace blankLines="0" />A Identifier:</dt>
        <dd>A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport protocol transport-protocol endpoint, session, etc.) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits, bits and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically-assigned statically assigned numeric identifiers (see e.g. (e.g., see <xref target="IANA-PROT"/>). target="IANA-PROT" format="default"/>). 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.
</t>

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

<t hangText="Hard Failure:">
<vspace blankLines="0" />A hard failure
	</dd>
        <dt>Soft Failure:</dt>
        <dd>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>Hard Failure:</dt>
        <dd>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.
</t>

<t hangText="Soft Failure:">
<vspace blankLines="0" />A soft failure is a recoverable condition in which a protocol does not operate in the prescribed manner but normal operation can be resumed automatically in a short period of time. For example, a simple packet-loss event that is subsequently recovered with a retransmission can be considered a soft failure.
</t>
</list>
</t>
</dd>
      </dl>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
      described in BCP 14 <xref target='RFC2119' /> target="RFC2119" format="default"/> <xref target='RFC8174' /> target="RFC8174" format="default"/> when, and only when, they
      appear in all capitals, as shown here.
</t>
    </section>
    <section title="Issues anchor="issues" numbered="true" toc="default">
      <name>Issues with the Specification of Transient Numeric Identifiers" anchor="issues">
<t>A recent survey of Identifiers</name>
      <t>Recent work on transient numeric identifier usage in protocol specifications and implementations <xref target="I-D.irtf-pearg-numeric-ids-history"/> target="RFC9414" format="default"/> <xref target="RFC9415" format="default"/> revealed that most of the issues discussed in this document arise as a result of one of the following conditions:

<list style="symbols">
<t>Protocol

</t>
      <ul spacing="normal">
        <li>protocol specifications that under-specify the requirements for under specify their identifiers</t>
<t>Protocol transient numeric identifiers</li>
        <li>protocol specifications that over-specify over specify their identifiers</t>
<t>Protocol transient numeric identifiers</li>
        <li>protocol implementations that simply fail to comply with the specified requirements</t>
</list>
</t> requirements</li>
      </ul>
      <t>Both under-specifying under specifying and over-specifying over specifying transient numeric identifiers is
   hazardous. TCP port numbers and sequence numbers local ports <xref target="RFC0793"/> and target="RFC0793" format="default"/>, as well as DNS TxID IDs
   <xref target="RFC1035"/> target="RFC1035" format="default"/>, were originally under-specified, under specified, leading to implementations that used resulted in
   predictable values and thus were vulnerable to numerous off-path
   attacks.  Over-specification, Over specification, as for IPv6 Interface Identifiers (IIDs)
   <xref target="RFC4291"/> target="RFC4291" format="default"/> and Fragment IPv6 Identification values <xref target="RFC2460"/>, target="RFC2460" format="default"/>, left
   implementations unable to respond to security and privacy issues
   stemming from the mandated or recommended algorithms -- IPv6 IIDs need not expose
   privacy-sensitive link-layer addresses, and predictable IPv6 Fragment
   Identifiers Header
   Identification values invite the same off-path attacks that plague TCP.</t>
      <t>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"/>.</t> target="RFC6056" format="default"/>.</t>
      <t>Clear specification of the interoperability requirements for the transient numeric identifiers will help identify possible algorithms that could be employed to generate them, them and also make evident if such identifiers are being over-specified. over specified. A protocol specification will usually also benefit from a vulnerability assessment of the transient numeric identifiers they specify, specify to prevent the corresponding considerations from being overlooked.
</t>
    </section>
    <section title="Common anchor="vulns" numbered="true" toc="default">
      <name>Common Flaws in the Generation of Transient Numeric Identifiers" anchor="vulns"> Identifiers</name>
      <t>This section briefly notes common flaws associated with the generation of transient numeric identifiers. Such common flaws include, but are not limited to:
<list style="symbols">
<t>Employing
</t>
      <ul spacing="normal">
        <li>employing trivial algorithms (e.g. (e.g., global counters) that result in predictable identifiers</t>
<t>Employing identifiers,</li>
        <li>employing the same identifier across contexts in which constancy is not required</t>
<t>Re-using required,</li>
        <li>reusing identifiers across different protocols or layers of the protocol stack</t>
<t>Initializing stack,</li>
        <li>initializing counters or timers to constant values, values when such initialization is not required</t>
<t>Employing required,</li>
        <li>employing the same increment space across different contexts</t>
<t>Use contexts, and</li>
        <li>use of flawed pseudo-random number generators (PRNGs).</t>
</list>
</t> Pseudorandom Number Generators (PRNGs).</li>
      </ul>
      <t>
   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>
   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>
   Re-using
   Reusing identifiers across different layers or protocols ties the
   security and privacy properties of the protocol re-using reusing the identifier to the
   security and privacy properties of the original identifier (over
   which the protocol re-using reusing the identifier may have no control
   regarding its generation).  Besides, when re-using reusing an identifier
   across protocols from different layers, the goal of isolating the
   properties of a layer from that those of another layer is broken, and the
   vulnerability assessment may be harder to perform, perform since the
   combined system, rather than each protocol in isolation isolation, will have to
   be assessed.
</t>
      <t>
   At times, a protocol needs to convey order information (whether it be
   sequence, timing, etc.).  In many cases, there is no reason for the
   corresponding counter or timer to be initialized to any specific
   value e.g.
   value, e.g., at system bootstrap. Similarly, there may not be a need for the difference between successive counted counter
values to be a predictable.
      </t>
      <t>
   A node that implements a per-context linear function may share the
   increment space among different contexts (please see the "Simple
   Hash-Based PRF-Based Algorithm" section in <xref target="I-D.irtf-pearg-numeric-ids-generation"/>). target="RFC9415" format="default"/>).
   Sharing the same increment space allows an attacker that can sample
   identifiers in other context to e.g. to, e.g., learn how many identifiers have
   been generated between two sampled values.
      </t>
      <t>Finally, some implementations have been found to employ flawed PRNGs (see e.g. (e.g., see <xref target="Klein2007"/>).</t> target="Klein2007" format="default"/>).</t>
    </section>
    <section title="Requirements anchor="reqs" numbered="true" toc="default">
      <name>Requirements for Transient Numeric Identifiers" anchor="reqs"> Identifiers</name>
      <t>Protocol specifications that employ transient numeric identifiers MUST <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 properties requirements are not met).
</t>
      <t>A vulnerability assessment of the aforementioned transient numeric identifiers MUST <bcp14>MUST</bcp14> be performed as part of the specification process.
Such vulnerability assessment should cover, at least, spoofing, tampering, repudiation, information disclosure, denial of service, DoS, and
elevation of privilege.

<list style="hanging">
<t>
Note: Section 8
</t>
<aside><t>NOTE: Sections <xref target="RFC9415" section="8" sectionFormat="bare" format="default"/> and Section 9 <xref target="RFC9415" section="9" sectionFormat="bare" format="default"/> of <xref target="I-D.irtf-pearg-numeric-ids-generation"/> target="RFC9415" format="default"/> 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"/> target="Shostack2014" format="default"/> for further guidance on threat modelling.
</t>
</list>
</t> modeling.
</t></aside>
      <t>Protocol specifications SHOULD NOT <bcp14>SHOULD NOT</bcp14> employ predictable transient numeric identifiers, except when such predictability is the result of their interoperability requirements.
</t>
      <t>Protocol specifications that employ transient numeric identifiers
   SHOULD
   <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="I-D.irtf-pearg-numeric-ids-generation"/>.</t> target="RFC9415" format="default"/>.</t>
      <t>
   As discussed in <xref target="intro"/>, target="intro" format="default"/>, use of cryptographic techniques for
   confidentiality and authentication might not eliminate all the
   issues associated with predictable transient numeric identifiers.
   Therefore, the advice from this section MUST <bcp14>MUST</bcp14> still be applied
   for cases where cryptographic techniques are employed for
   confidentiality or authentication of the associated
   transient numeric identifiers. are employed.
</t>
    </section>
    <section title="IANA Considerations" anchor="iana-considerations">
<t>There are anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA registries within this document. </t> actions.</t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This entire document is about the security and privacy implications of transient numeric identifiers, identifiers and formally updates <xref target="RFC3552"/> target="RFC3552" format="default"/> such that the security and privacy implications of transient numeric identifiers are addressed when writing the "Security Considerations" section of future RFCs.
</t>
    </section>

    <section title="Acknowledgements">
<t>The authors would like to thank Bernard Aboba, Brian Carpenter, Roman Danyliw, Theo de Raadt, Lars Eggert, Russ Housley, Benjamin Kaduk, Charlie Kaufman, Erik Kline, Alvaro Retana, Joe Touch, Michael Tuexen, Robert Wilton, and Paul Wouters, for providing valuable comments on earlier versions of this document.</t>

<t>The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, for providing valuable comments on <xref target="I-D.gont-predictable-numeric-ids"/> , on which the present document is based.</t>

<t>The authors would like to thank Diego Armando Maradona for his magic and inspiration.</t>

    </section>
  </middle>
  <back>
  <references title='Normative References'>
	<?rfc include="reference.RFC.2119" ?>
	<?rfc include="reference.RFC.8174" ?>

<!-- Sec Cons -->
	<?rfc include="reference.RFC.3552" ?>

<!--
	<?rfc include="reference.RFC.4086" ?>
-->

<!--
	<?rfc include="reference.RFC.6151" ?>
	<?rfc include="reference.RFC.7098" ?>
-->

<displayreference target="I-D.gont-predictable-numeric-ids" to="PREDICTABLE-NUMERIC-IDS"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
  </references>

  <references title='Informative References'>

<!-- IPv6 IIDs  -->
	<?rfc include="reference.RFC.7721" ?>
	<?rfc include="reference.RFC.7217" ?>
	<?rfc include="reference.RFC.7707" ?>

<!-- Frag IDs -->
	<?rfc include="reference.RFC.6274" ?>
	<?rfc include="reference.RFC.7739" ?>
      <references>
        <name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7707.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6274.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7739.xml"/>

        <reference anchor="Sanfilippo1998a" target="https://seclists.org/bugtraq/1998/Dec/48">
          <front>
            <title>about the ip header id</title>
            <author initials="S." surname="Sanfilippo" fullname="S. fullname="Salvatore Sanfilippo">
				<organization></organization>
              <organization/>
            </author>
			<date/>
            <date month="December" year="1998"/>
          </front>
		<seriesInfo name="Post
	  <refcontent>message to the Bugtraq mailing-list," value="Mon Dec 14 1998" /> mailing list</refcontent>
        </reference>

<!-- TCP sequence numbers -->
	<?rfc include="reference.RFC.0793" ?>
	<?rfc include="reference.RFC.6528" ?>  <!-- TCP SEQ randomization -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6528.xml"/>

	<reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb/papers/ipext.pdf">
          <front>
            <title>Security Problems in the TCP/IP Protocol Suite</title>
            <author initials="S." surname="Bellovin" fullname="Bellovin">
				<organization></organization> fullname="S. M. Bellovin">
              <organization/>
            </author>
            <date year="Computer month="April" year="1989"/>
          </front>
	  <refcontent>Computer Communications Review, vol. 19, no. 2, pp. 32-48, 1989"/>
		</front> 32-48</refcontent>
        </reference>

        <reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/papers/117.pdf">
          <front>
            <title>A Weakness in the 4.2BSD UNIX TCP/IP Software</title>
            <author initials="R." surname="Morris" fullname="Robert Morris">
				<organization></organization>
              <organization/>
            </author>
            <date year="1985"/> year="1985" month="February"/>
          </front>
		<seriesInfo name="CSTR 117," value="AT&amp;T
	  <refcontent>CSTR 117, AT&amp;T Bell Laboratories, Murray Hill, NJ"/> NJ</refcontent>
        </reference>

<!-- IPv6 -->
	<?rfc include="reference.RFC.2460" ?>

		<!-- Port randomization -->
	<?rfc include="reference.RFC.6056" ?>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6056.xml"/>

        <reference anchor="Silbersack2005" target="http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdff"> target="http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf">
          <front>
            <title>Improving TCP/IP security through randomization without sacrificing interoperability</title>
            <author initials="M.J." initials="M." surname="Silbersack" fullname="Michael James Silbersack">
              <organization>The FreeBSD Project</organization>
            </author>
            <date year="2005"/> year="2005" month="January"/>
          </front>
		<seriesInfo name="EuroBSDCon 2005" value="Conference"/>
	  <refcontent>EuroBSDCon 2005 Conference</refcontent>
        </reference>

	<?rfc include="reference.I-D.gont-predictable-numeric-ids" ?>

<!--
	<?rfc include="reference.RFC.1321" ?>
-->

<!-- Pervasive Monitoring -->
	<?rfc include="reference.RFC.7258" ?>

<!-- DNS -->
	<?rfc include="reference.RFC.1035" ?>

<!-- IPv6 addresses -->
	<?rfc include="reference.RFC.4291" ?>

<!-- PNRG -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gont-predictable-numeric-ids.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/>
        <reference anchor="TCPT-uptime" target="https://seclists.org/bugtraq/2001/Mar/182">
          <front>
            <title>TCP Timestamping - Obtaining System Uptime Remotely</title>
            <author initials="B." surname="McDanel" fullname="Bret McDanel">
              <organization>Securiteam</organization>
            </author>
            <date month="March" year="2001"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>

<reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf">
          <front>
            <title>OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization>Trusteer</organization>
            </author>
            <date year="2007"/> year="2007" month="October"/>
          </front>
        </reference>

        <reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf">
          <front>
			<title>ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PROTOCOL</title>
            <title>Addressing Weakness in the Domain Name System Protocol</title>
            <author initials="C." surname="Schuba" fullname="Christoph Schuba">
				<organization></organization>
              <organization/>
            </author>
            <date year="1993"/> year="1993" month="August"/>
          </front>
        </reference>

        <reference anchor="Shostack2014">
          <front>
            <title>Threat Modeling: Designing for Security</title>
            <author initials="A." surname="Shostack" fullname="Adam Shostack">
				<organization></organization>
              <organization/>
            </author>
            <date year="2014" month="February"/>
          </front>
	  <refcontent>Wiley, 1st edition</refcontent>
        </reference>

<reference anchor='RFC9414' target='https://www.rfc-editor.org/info/rfc9414'>
<front>
<title>Unfortunate History of Transient Numeric Identifiers</title>
<author initials='F' surname='Gont' fullname='Fernando Gont'>
<organization />
</author>
<author initials='I' surname='Arce' fullname='Ivan Arce'>
<organization />
</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/rfc941v'>
<front>
<title>On the Generation of Transient Numeric Identifiers</title>
<author initials='F' surname='Gont' fullname='Fernando Gont'>
<organization />
</author>
<author initials='I' surname='Arce' fullname='Ivan Arce'>
<organization />
</author>
<date year="2014"/> year='2023' month='July'/>
</front>
<seriesInfo name="Wiley, " value="1st edition"/> name="RFC" value="9415"/>
<seriesInfo name="DOI" value="10.17487/RFC9415"/>
</reference>

	<?rfc include="reference.I-D.irtf-pearg-numeric-ids-history" ?>
	<?rfc include="reference.I-D.irtf-pearg-numeric-ids-generation" ?>

        <reference anchor="IANA-PROT" target="https://www.iana.org/protocols">
          <front>
	    <title>Protocol Registries</title>
			<author initials="" surname="IANA" fullname="IANA">
				<organization></organization>
	    <author>
	      <organization>IANA</organization>
	      </author>

			<date/>
            </front>
<!--
		<seriesInfo name="" value="Federal Information Processing Standards Publication 180-4"/>
-->
	</reference>
      </references>
    </references>
    <section numbered="false" toc="default">

      <name>Acknowledgements</name>
      <t>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>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"/>, on which the present document is based.</t>
      <t>The authors would like to thank <contact fullname="Diego Armando Maradona"/> for his magic and inspiration.</t>
    </section>
  </back>
</rfc>