rfc9415xml2.original.xml   rfc9415.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT proces
sors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="no" ?>
<rfc category="info" docName="draft-irtf-pearg-numeric-ids-generation-12" ipr="t <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="
rust200902" submissionType="IRTF"> info" consensus="true" docName="draft-irtf-pearg-numeric-ids-generation-12" numb
er="9415" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="tr
<front> ue" tocDepth="2" symRefs="true" sortRefs="true" version="3">
<title abbrev="Generation of Transient Numeric IDs">On the Generation of Transie
nt Numeric Identifiers</title>
<!-- xml2rfc v2v3 conversion 3.15.3 -->
<front>
<title abbrev="Generation of Transient Numeric IDs">On the Generation of Tra
nsient Numeric Identifiers</title>
<seriesInfo name="RFC" value="9415"/>
<author fullname="Fernando Gont" initials="F." surname="Gont"> <author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks">SI6 Networks</organization> <organization abbrev="SI6 Networks">SI6 Networks</organization>
<address> <address>
<postal> <postal>
<street>Segurola y Habana 4310 7mo piso</street> <street>Segurola y Habana 4310 7mo piso</street>
<city>Ciudad Autonoma de Buenos Aires</city> <city>Ciudad Autonoma de Buenos Aires</city>
<region>Buenos Aires</region>
<country>Argentina</country> <country>Argentina</country>
</postal> </postal>
<!-- <phone>+54 11 4650 8472</phone> -->
<email>fgont@si6networks.com</email> <email>fgont@si6networks.com</email>
<uri>https://www.si6networks.com</uri> <uri>https://www.si6networks.com</uri>
</address>
</address>
</author> </author>
<author fullname="Ivan Arce" initials="I." surname="Arce"> <author fullname="Ivan Arce" initials="I." surname="Arce">
<organization abbrev="Quarkslab">Quarkslab</organization> <organization abbrev="Quarkslab">Quarkslab</organization>
<address> <address>
<postal> <postal>
<street>Segurola y Habana 4310 7mo piso</street> <street>Segurola y Habana 4310 7mo piso</street>
<city>Ciudad Autonoma de Buenos Aires</city> <city>Ciudad Autonoma de Buenos Aires</city>
<region>Buenos Aires</region>
<country>Argentina</country> <country>Argentina</country>
</postal> </postal>
<email>iarce@quarkslab.com</email> <email>iarce@quarkslab.com</email>
<uri>https://www.quarkslab.com</uri> <uri>https://www.quarkslab.com</uri>
</address>
</address>
</author> </author>
<date year="2023" month="July"/>
<workgroup>Privacy Enhancements and Assessments</workgroup>
<date/> <keyword>security</keyword>
<keyword>vulnerability</keyword>
<workgroup>Internet Research Task Force (IRTF)</workgroup> <keyword>algorithm</keyword>
<keyword>attack</keyword>
<!-- <keyword>fingerprinting</keyword>
<area>Internet</area>
<workgroup>Dynamic Host Configuration (dhc)</workgroup>
<!-- <area/> -->
<!-- <workgroup/> -->
<abstract> <abstract>
<t> <t>
This document performs an analysis of the security and privacy implications of d This document performs an analysis of the security and privacy implications of d
ifferent types of "transient numeric identifiers" used in IETF protocols, and tr ifferent types of "transient numeric identifiers" used in IETF protocols and tri
ies to categorize them based on their interoperability requirements and their as es to categorize them based on their interoperability requirements and their ass
sociated failure severity when such requirements are not met. Subsequently, it p ociated failure severity when such requirements are not met. Subsequently, it pr
rovides advice on possible algorithms that could be employed to satisfy the inte ovides advice on possible algorithms that could be employed to satisfy the inter
roperability requirements of each identifier category, while minimizing the nega operability requirements of each identifier category while minimizing the negati
tive security and privacy implications, thus providing guidance to protocol desi ve security and privacy implications, thus providing guidance to protocol design
gners and protocol implementers. Finally, it describes a number of algorithms th ers and protocol implementers. Finally, it describes a number of algorithms that
at have been employed in real implementations to generate transient numeric iden have been employed in real implementations to generate transient numeric identi
tifiers, and analyzes their security and privacy properties. This document is a fiers and analyzes their security and privacy properties. This document is a pro
product of the Privacy Enhancement and Assessment Research Group (PEARG) in the duct of the Privacy Enhancements and Assessments Research Group (PEARG) in the I
IRTF. RTF.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>
Networking protocols employ a variety of transient numeric identifiers for diffe
rent protocol objects, such as IPv4 and IPv6 Identification values <xref target=
"RFC0791" format="default"/> <xref target="RFC8200" format="default"/>, IPv6 Int
erface Identifiers (IIDs) <xref target="RFC4291" format="default"/>, transport-p
rotocol ephemeral port numbers <xref target="RFC6056" format="default"/>, TCP In
itial Sequence Numbers (ISNs) <xref target="RFC9293" format="default"/>, NTP Ref
erence IDs (REFIDs) <xref target="RFC5905" format="default"/>, and DNS IDs <xref
target="RFC1035" format="default"/>. These identifiers typically have specific
requirements (e.g., uniqueness during a specified period of time) that must be s
atisfied such that they do not result in negative interoperability implications
and an associated failure severity when such requirements are not met.</t>
<aside>
<t>NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".</t>
</aside>
<section title="Introduction" anchor="intro"> <t>For more than 30 years, a large number of implementations of IETF protocols h
<t>Networking protocols employ a variety of transient numeric identifiers for di ave been subject to a variety of attacks, with effects ranging from Denial of Se
fferent protocol objects, such as IPv4 and IPv6 Fragment Identifiers <xref targe rvice (DoS) or data injection to information leakages that could be exploited fo
t="RFC0791"/> <xref target="RFC8200"/>, IPv6 Interface Identifiers (IIDs) <xref r pervasive monitoring <xref target="RFC7258" format="default"/>. The root cause
target="RFC4291"/>, transport protocol ephemeral port numbers <xref target="RFC6 of these issues has been, in many cases, the poor selection of transient numeri
056"/>, TCP Initial Sequence Numbers (ISNs) <xref target="RFC0793"/>, and DNS Qu c identifiers in such protocols, usually as a result of insufficient or misleadi
ery IDs <xref target="RFC1035"/>.<!-- ng specifications. While it is generally trivial to identify an algorithm that c
Network protocols employ a variety of transient numeric identifiers for differen an satisfy the interoperability requirements of a given transient numeric identi
t protocol entities, ranging from DNS Transaction IDs (TxIDs) to transport proto fier, empirical evidence exists that doing so without negatively affecting the s
col ephemeral ports (e.g. TCP ephemeral ports) or IPv6 Interface Identifiers (II ecurity and/or privacy properties of the aforementioned protocols is prone to er
Ds).--> These identifiers usually have specific interoperability requirements (e ror <xref target="RFC9414" format="default"/>.</t>
.g. uniqueness during a specified period of time) that must be satisfied such th <t>For example, implementations have been subject to security and/or priva
at they do not result in negative interoperability implications, and an associat cy issues resulting from:</t>
ed failure severity when such requirements are not met, ranging from soft to har <ul spacing="normal">
d failures. <li>predictable IPv4 or IPv6 Identification values (e.g., see <xref targ
</t> et="Sanfilippo1998a" format="default"/>, <xref target="RFC6274" format="default"
/>, and <xref target="RFC7739" format="default"/>),</li>
<t>For more than 30 years, a large number of implementations of IETF protocols h <li>predictable IPv6 IIDs (e.g., see <xref target="RFC7217" format="defa
ave been subject to a variety of attacks, with effects ranging from Denial of Se ult"/>, <xref target="RFC7707" format="default"/>, and <xref target="RFC7721" fo
rvice (DoS) or data injection, to information leakages that could be exploited f rmat="default"/>),</li>
or pervasive monitoring <xref target="RFC7258"/>. The root cause of these issues <li>predictable transport-protocol ephemeral port numbers (e.g., see <xr
has been, in many cases, the poor selection of transient numeric identifiers in ef target="RFC6056" format="default"/> and <xref target="Silbersack2005" format=
such protocols, usually as a result of insufficient or misleading specification "default"/>),</li>
s. While it is generally trivial to identify an algorithm that can satisfy the i <li>predictable TCP Initial Sequence Numbers (ISNs) (e.g., see <xref tar
nteroperability requirements of a given transient numeric identifier, empirical get="Morris1985" format="default"/>, <xref target="Bellovin1989" format="default
evidence exists that doing so without negatively affecting the security and/or p "/>, and <xref target="RFC6528" format="default"/>),</li>
rivacy properties of the aforementioned protocols is prone to error <xref target <li>predictable initial timestamps in TCP timestamps options (e.g., see
="I-D.irtf-pearg-numeric-ids-history"/>.</t> <xref target="TCPT-uptime" format="default"/> and <xref target="RFC7323" format=
"default"/>), and</li>
<t>For example, implementations have been subject to security and/or privacy iss <li>predictable DNS IDs (see, e.g., <xref target="Schuba1993" format="de
ues resulting from: fault"/> and <xref target="Klein2007" format="default"/>).</li>
</ul>
<list style="symbols"> <t>
<t>Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. <xref target="Sanfili
ppo1998a"/>, <xref target="RFC6274"/>, and <xref target="RFC7739"/>)</t>
<t>Predictable IPv6 IIDs (see e.g. <xref target="RFC7721"/>, <xref target="RFC77
07"/>, and <xref target="RFC7217"/>)</t>
<t>Predictable transport protocol ephemeral port numbers (see e.g. <xref target=
"RFC6056"/> and <xref target="Silbersack2005"/>)</t>
<t>Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. <xref target="Morri
s1985"/>, <xref target="Bellovin1989"/>, and <xref target="RFC6528"/>)</t>
<t>Predictable initial timestamps in TCP timestamps Options (see e.g. <xref targ
et="TCPT-uptime"/> and <xref target="RFC7323"/>)</t>
<t>Predictable DNS Query IDs (see e.g. <xref target="Schuba1993"/> and <xref tar
get="Klein2007"/>)</t>
</list>
Recent history indicates that when new protocols are standardized or new protoco
l implementations are produced, the security and privacy properties of the assoc
iated transient numeric identifiers tend to be overlooked, and inappropriate alg
orithms to generate transient numeric identifiers are either suggested in the sp
ecifications or selected by implementers. As a result, it should be evident that
advice in this area is warranted.
</t>
<t>We note that the use of cryptographic techniques may readily mitigate some of
the issues arising from predictable transient numeric identifiers. For example,
cryptographic integrity and 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 counte
rs) for generating transient numeric identifiers could still result in informati
on leakages even when cryptographic techniques are employed.
</t>
<t>This document contains a non-exhaustive survey of transient numeric identifie
rs employed in various IETF protocols, and aims to categorize such identifiers b
ased on their interoperability requirements, and the associated failure severity
when such requirements are not met. Subsequently, it provides advice on possibl
e algorithms that could be employed to satisfy the interoperability requirements
of each category, while minimizing negative security and privacy implications.
Finally, it analyzes several algorithms that have been employed in real implemen
tations to meet such requirements, and analyzes their security and privacy prope
rties.
</t>
<t>This document represents the consensus of the Privacy Enhancement and Assessm
ent Research Group (PEARG).</t>
<!--
[fgont] Quite esto, ya que hay mas secciones, y es medio en vano describi que ha
ce cada seccion
<t> <xref target="categorizing"/> categorizes identifiers in terms of their inte
roperability requirements and failure modes, such that possible algorithms for t
hem can be discussed and analyzed.
<xref target="timeline"/> provides a non-exhaustive timeline regarding vulnera
bility disclosures related to predictable identifiers.
</t>-->
</section>
<section title="Terminology" anchor="terminology">
<t>
<list style="hanging">
<t hangText="Transient Numeric Identifier:">
<vspace blankLines="0" />A data object in a protocol specification that can be u
sed to definitely distinguish a protocol object (a datagram, network interface,
transport protocol endpoint, session, etc.) from all other objects of the same t
ype, in a given context. Transient numeric identifiers are usually defined as a
series of bits, and represented using integer values. These identifiers are typi
cally dynamically selected, as opposed to statically-assigned numeric identifier
s (see e.g. <xref target="IANA-PROT"/>). We note that different transient numeri
c identifiers may have additional requirements or properties depending on their
specific use in a protocol. We use the term "transient numeric identifier" (or s
imply "numeric identifier" or "identifier" as short forms) as a generic term to
refer to any data object in a protocol specification that satisfies the identifi
cation property stated above.
</t>
<t hangText="Failure Severity:">
<vspace blankLines="0" />The interoperability consequences of a failure to compl
y with the interoperability requirements of a given identifier. Severity conside
rs the worst potential consequence of a failure, determined by the system damage
and/or time lost to repair the failure. In this document we define two types of
failure severity: "soft failure" and "hard failure".
</t>
<t hangText="Soft Failure:">
<vspace blankLines="0" />A soft failure is a recoverable condition in which a pr
otocol does not operate in the prescribed manner but normal operation can be res
umed automatically in a short period of time. For example, a simple packet-loss
event that is subsequently recovered with a packet-retransmission can be conside
red a soft failure.
</t>
<t hangText="Hard Failure:">
<vspace blankLines="0" />A hard failure is a non-recoverable condition in which
a protocol does not operate in the prescribed manner or it operates with excessi
ve degradation of service. For example, an established TCP connection that is ab
orted due to an error condition constitutes, from the point of view of the trans
port protocol, a hard failure, since it enters a state from which normal operati
on cannot be resumed.
</t>
</list>
</t>
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target='RFC2119' /> <xref target='RFC8174' /> wh
en, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section title="Threat Model" anchor="threat-model"> Recent history indicates that, when new protocols are standardized or new protoc
<!-- ol implementations are produced, the security and privacy properties of the asso
<t>Throughout this document, we assume an attacker does not have physical or log ciated transient numeric identifiers tend to be overlooked, and inappropriate al
ical access to the system(s) being attacked, and cannot necessarily observe all gorithms to generate such identifiers are either suggested in the specifications
the packets being transferred between the sender and the receiver(s) of the or selected by implementers. As a result, advice in this area is warranted.
target protocol, but may be able to observe some of them. However, we assume the
attacker can send any traffic to the target device(s), to e.g. sample transient
numeric identifiers employed by such device(s).
</t> </t>
<t>We note that the use of cryptographic techniques may readily mitigate s
<t>Throughout this document, we do not consider on-path attacks. That is, we ass ome of the issues arising from predictable transient numeric identifiers. For ex
ume an attacker does not have physical or logical access to the system(s) being ample, cryptographic authentication can readily mitigate data injection attacks
attacked, and that the attacker can only observe traffic explicitly directed to even in the presence of predictable transient numeric identifiers (such as "sequ
the attacker. Similarly, an attacker cannot observe traffic transferred between ence numbers"). However, use of flawed algorithms (such as global counters) for
a sender and the receiver(s) of a target protocol, but may be able to interact w generating transient numeric identifiers could still result in information leaka
ith any of these entities, including by e.g. sending traffic to them to sample t ges even when cryptographic techniques are employed.
ransient numeric identifiers employed by the target systems when communicating w
ith the attacker.
</t> </t>
<t>For example, when analyzing vulnerabilities associated with TCP Initial Seque <t>This document contains a non-exhaustive survey of transient numeric ide
nce Numbers (ISNs), we consider the attacker is unable to capture network traffi ntifiers employed in various IETF protocols and aims to categorize such identifi
c corresponding to a TCP connection between two other hosts. However, we conside ers based on their interoperability requirements and the associated failure seve
r the attacker is able to communicate with any of these hosts (e.g., establish a rity when such requirements are not met. Subsequently, it provides advice on pos
TCP connection with any of them), to e.g. sample the TCP ISNs employed by these sible algorithms that could be employed to satisfy the interoperability requirem
systems when communicating with the attacker.</t> ents of each category while minimizing negative security and privacy implication
s. Finally, it analyzes several algorithms that have been employed in real imple
<t>Similarly, when considering host-tracking attacks based on IPv6 interface ide mentations to meet such requirements and analyzes their security and privacy pro
ntifiers, we consider an attacker may learn the IPv6 address employed by a victi perties.
m node if e.g. the address becomes exposed as a result of the victim node commun
icating with an attacker-operated server. Subsequently, an attacker may perform
host-tracking by probing a set of target addresses composed by a set of target p
refixes and the IPv6 interface identifier originally learned by the attacker. Al
ternatively, an attacker may perform host tracking if e.g. the victim node commu
nicates with an attacker-operated server as it moves from one location to anothe
r, those exposing its configured addresses. We note that none of these scenarios
requires the attacker observe traffic not explicitly directed to the attacker.
</t> </t>
<t>This document represents the consensus of the Privacy Enhancements and Assessments Research Group (PEARG).</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section title="Issues with the Specification of Transient Numeric Identifiers" <name>Terminology</name>
anchor="issues"> <dl newline="true" spacing="normal">
<t>While assessing protocol specifications regarding the use of transient numeri <dt>Transient Numeric Identifier:</dt>
c identifiers, we have found that most of the issues discussed in this document <dd>A data object in a protocol specification that can be used to defini
arise as a result of one of the following conditions: tely distinguish a protocol object (a datagram, network interface, transport-pro
tocol endpoint, session, etc.) from all other objects of the same type, in a giv
<list style="symbols"> en context. Transient numeric identifiers are usually defined as a series of bit
<t>Protocol specifications that under-specify the requirements for their transie s and represented using integer values. These identifiers are typically dynamica
nt numeric identifiers</t> lly selected, as opposed to statically assigned numeric identifiers (see, e.g.,
<t>Protocol specifications that over-specify their transient numeric identifiers <xref target="IANA-PROT" format="default"/>). We note that different transient n
</t> umeric identifiers may have additional requirements or properties depending on t
<t>Protocol implementations that simply fail to comply with the specified requir heir specific use in a protocol. We use the term "transient numeric identifier"
ements</t> (or simply "numeric identifier" or "identifier" as short forms) as a generic ter
</list> m to refer to any data object in a protocol specification that satisfies the ide
</t> ntification property stated above.
</dd>
<t>A number of protocol specifications (too many of them) have simply overlooked <dt>Failure Severity:</dt>
the security and privacy implications of transient numeric identifiers <xref ta <dd>The interoperability consequences of a failure to comply with the in
rget="I-D.irtf-pearg-numeric-ids-history"/>. Examples of them are the specificat teroperability requirements of a given identifier. Severity considers the worst
ion of TCP ephemeral ports in <xref target="RFC0793"/>, the specification of TCP potential consequence of a failure, determined by the system damage and/or time
sequence numbers in <xref target="RFC0793"/>, or the specification of the DNS Q lost to repair the failure. In this document, we define two types of failure sev
uery ID in <xref target="RFC1035"/>.</t> erity: "soft failure" and "hard failure".
</dd>
<t>On the other hand, there are a number of protocol specifications that over-sp <dt>Soft Failure:</dt>
ecify some of their associated transient numeric identifiers. For example, <xref <dd>A recoverable condition in which a protocol does not operate in the
target="RFC4291"/> essentially overloads the semantics of IPv6 Interface Identi prescribed manner but normal operation can be resumed automatically in a short p
fiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs, when the intero eriod of time. For example, a simple packet-loss event that is subsequently reco
perability requirement of uniqueness could be achieved in other ways that do not vered with a packet retransmission can be considered a soft failure.
result in negative security and privacy implications <xref target="RFC7721"/>. </dd>
Similarly, <xref target="RFC2460"/> suggested the use of a global counter for th <dt>Hard Failure:</dt>
e generation of Fragment Identification values, when the interoperability proper <dd>A non-recoverable condition in which a protocol does not operate in
ties of uniqueness per {IPv6 Source Address, IPv6 Destination Address} could be the prescribed manner or it operates with excessive degradation of service. For
achieved with other algorithms that do not result in negative security and priva example, an established TCP connection that is aborted due to an error condition
cy implications <xref target="RFC7739"/>.</t> constitutes, from the point of view of the transport protocol, a hard failure,
since it enters a state from which normal operation cannot be resumed.
<t>Finally, there are protocol implementations that simply fail to comply with e </dd>
xisting protocol specifications. For example, some popular operating systems (no </dl>
tably Microsoft Windows) still fail to implement transport protocol ephemeral po
rt randomization, as recommended in <xref target="RFC6056"/>.</t>
</section> </section>
<section anchor="threat-model" numbered="true" toc="default">
<name>Threat Model</name>
<section title="Protocol Failure Severity" anchor="failure-severity"> <t>Throughout this document, we do not consider on-path attacks. That is, we ass
<t><xref target="terminology"/> defines the concept of "Failure Severity", along ume the attacker does not have physical or logical access to the system(s) being
with two types of failure severities that we employ throughout this document: s attacked and that the attacker can only observe traffic explicitly directed to
oft and hard.</t> the attacker. Similarly, an attacker cannot observe traffic transferred between
the sender and the receiver(s) of a target protocol but may be able to interact
<t>Our analysis of the severity of a failure is performed from the point of view with any of these entities, including by, e.g., sending any traffic to them to s
of the protocol in question. However, the corresponding severity on the upper p ample transient numeric identifiers employed by the target hosts when communicat
rotocol (or application) might not be the same as that of the protocol in questi ing with the attacker.
on. For example, a TCP connection that is aborted might or might not result in a
hard failure of the upper application: if the upper application can establish a
new TCP connection without any impact on the application, a hard failure at the
TCP protocol may have no severity at the application level. On the other hand,
if a hard failure of a TCP connection results in excessive degradation of servic
e at the application layer, it will also result in a hard failure at the applica
tion.
</t> </t>
</section>
<section title="Categorizing Transient Numeric Identifiers" anchor="categorizing <t>For example, when analyzing vulnerabilities associated with TCP Initial
"> Sequence Numbers (ISNs), we consider the attacker is unable to capture network
<t>This section includes a non-exhaustive survey of transient numeric identifier traffic corresponding to a TCP connection between two other hosts. However, we c
s, which are representative of all the possible combinations of interoperability onsider the attacker is able to communicate with any of these hosts (e.g., estab
requirements and failure severities found in popular protocols from different l lish a TCP connection with any of them) to, e.g., sample the TCP ISNs employed b
ayers. Additionally, it proposes a number of categories that can accommodate the y these hosts when communicating with the attacker.</t>
se identifiers based on their interoperability requirements and their associated <t>Similarly, when considering host-tracking attacks based on IPv6 Interfa
failure severity (soft or hard). ce Identifiers, we consider an attacker may learn the IPv6 address employed by a
victim host if, e.g., the address becomes exposed as a result of the victim hos
<list style="hanging"> t communicating with an attacker-operated server. Subsequently, an attacker may
<t hangText="NOTE:"> perform host-tracking by probing a set of target addresses composed by a set of
<vspace blankLines="0"/> target prefixes and the IPv6 Interface Identifier originally learned by the atta
All other transient numeric identifiers that were analyzed as part of this effor cker.
t could be accommodated into one of the existing categories from <xref target="s Alternatively, an attacker may perform host-tracking if, e.g., the victim
urvey-table"/>. host communicates with an attacker-operated server as it moves from one location
</t> to another, thereby exposing its configured addresses. We note that none of the
</list> se scenarios require the attacker observe traffic not explicitly directed to the
attacker.
</t> </t>
</section>
<section anchor="issues" numbered="true" toc="default">
<name>Issues with the Specification of Transient Numeric Identifiers</name
>
<t>While assessing IETF protocol specifications regarding the use of trans
ient numeric identifiers, we have found that most of the issues discussed in thi
s document arise as a result of one of the following conditions:
<!-- [fgont] Basado en el contenido de la seccion anterior, tal vez esta tabla p
odria contener una columna adicional que indique si el problema es "under-specif
ication", "over-specification", o "implementation-flaw" ?
No se si aportaria mucho en terminos de categorizar, aunque si tal vez en el sen
tido de servir de "sample" de cual es el rigen de los problemas.
Ideas?
<texttable title="Survey of Transient Numeric Identifiers" style="all" ancho
r="survey-table">
<ttcol align="center">Identifier</ttcol> <ttcol align="center">Interoper
ability Requirements</ttcol> <ttcol align="center">Failure Severity</ttcol>
<c>IPv6 Frag ID</c> <c>Uniqueness (for IP address pair)</c>
<c>Soft/Hard (1)</c>
<c>IPv6 IID</c> <c>Uniqueness (and stable within IPv6 pre
fix) (2)</c> <c>Soft (3)</c>
<c>TCP ISN</c> <c>Monotonically-increasing (4)</c>
<c>Hard (4)</c>
<c>TCP initial timestamp</c> <c>Monotonically-increasing (5)</
c> <c>Hard (5)</c>
<c>TCP eph. port</c><c>Uniqueness (for connection ID)</c>
<c>Hard</c>
<c>IPv6 Flow Label</c> <c>Uniqueness</c>
<c>None (6)</c>
<c>DNS Query ID</c> <c>Uniqueness</c>
<c>None (7)</c>
</texttable>
<t>NOTE:
<list style="hanging">
<t hangText="(1)">
<vspace blankLines="0" />While a single collision of Fragment ID values would si
mply lead to a single packet drop (and hence a "soft" failure), repeated collisi
ons at high data rates might result in self-propagating collisions of Fragment I
Ds, thus possibly leading to a hard failure <xref target="RFC4963"/>.</t>
<t hangText="(2)">
<vspace blankLines="0" />While the interoperability requirements are simply that
the Interface ID results in a unique IPv6 address, for operational reasons it i
s typically desirable that the resulting IPv6 address (and hence the correspondi
ng Interface ID) be stable within each network <xref target="RFC7217"/> <xref ta
rget="RFC8064"/>.</t>
<t hangText="(3)">
<vspace blankLines="0" />While IPv6 Interface IDs must result in unique IPv6 add
resses, IPv6 Duplicate Address Detection (DAD) <xref target="RFC4862"/> allows f
or the detection of duplicate addresses, and hence such Interface ID collisions
can be recovered.</t>
<t hangText="(4)">
<vspace blankLines="0" />In theory, there are no interoperability requirements f
or TCP Initial Sequence Numbers (ISNs), since the TIME-WAIT state and TCP's "qui
et time" concept take care of old segments from previous incarnations of a conne
ction. However, a widespread optimization allows for a new incarnation of a prev
ious connection to be created if the ISN of the incoming SYN is larger than the
last sequence number seen in that direction for the previous incarnation of the
connection. Thus, monotonically-increasing TCP ISNs allow for such optimization
to work as expected <xref target="RFC6528"/>, and can help avoid connection-esta
blishment failures.</t>
<t hangText="(5)">
<vspace blankLines="0" />Strictly speaking, there are no interoperability requir
ements for the *initial* TCP timestamp employed by a TCP instance (i.e., the TS
Value (TSval) in a segment with the SYN bit set). However, some TCP implementati
ons allow a new incarnation of a previous connection to be created if the TSval
of the incoming SYN is larger than the last TSval seen in that direction for the
previous incarnation of the connection (please see <xref target="RFC6191"/>). T
hus, monotonically-increasing TCP initial timestamps (across connections to the
same endpoint) allow for such optimization to work as expected <xref target="RFC
6191"/>, and can help avoid connection-establishment failures.</t>
<t hangText="(6)">
<vspace blankLines="0" />The IPv6 Flow Label <xref target="RFC6437"/>, along wit
h the Source and Destination IPv6 addresses, is typically employed for load shar
ing <xref target="RFC7098"/>. Reuse of a Flow Label value for the same set {Sour
ce Address, Destination Address} would typically cause both flows to be multiple
xed onto the same link. However, as long as this does not occur deterministicall
y, it will not result in any negative implications.</t>
<t hangText="(7)">
<vspace blankLines="0" />DNS Query IDs are employed, together with the Source Ad
dress, Destination Address, Source Port, and Destination Port, to match DNS requ
ests and responses. However, since an implementation knows which DNS requests we
re sent for that set of {Source Address, Destination Address, Source Port, and D
estination Port, Query ID}, a collision of Query IDs would result, if anything,
in a small performance penalty (the response would nevertheless be discarded whe
n it is found that it does not answer the query sent in the corresponding DNS qu
ery).</t>
</list>
</t> </t>
<ul spacing="normal">
<li>protocol specifications that under specify their transient numeric i
dentifiers</li>
<li>protocol specifications that over specify their transient numeric id
entifiers</li>
<li>protocol implementations that simply fail to comply with the specifi
ed requirements</li>
</ul>
<t>A number of IETF protocol specifications under specified their transien
t numeric identifiers, thus leading to implementations that were vulnerable to n
umerous off-path
attacks. Examples of them are the specification of TCP local ports in <xref t
arget="RFC0793" format="default"/> or the specification of the DNS ID in <xref t
arget="RFC1035" format="default"/>.</t>
<t>Based on the survey above, we can categorize identifiers as follows:</t> <aside><t>NOTE: The TCP local port in an active OPEN request is commonly known a s the "ephemeral port" of the corresponding TCP connection <xref target="RFC6056 " format="default"/>.</t></aside>
<texttable title="Identifier Categories" style="all" anchor="cat-table"> <t>On the other hand, there are a number of IETF protocol specifications t
<ttcol align="center">Cat #</ttcol><ttcol align="center">Category</ttcol hat over specify some of their associated transient numeric identifiers. For exa
><ttcol align="center">Sample Proto IDs</ttcol> mple, <xref target="RFC4291" format="default"/> essentially overloads the semant
<c>1</c><c>Uniqueness (soft failure)</c><c>IPv6 Flow L., DNS Query ID</c> ics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in th
<c>2</c><c>Uniqueness (hard failure)</c><c>IPv6 Frag ID, TCP ephemeral po e IPv6 IIDs when the interoperability requirement of uniqueness could be achieve
rt</c> d in other ways that do not result in negative security and privacy implications
<c>3</c><c>Uniqueness, stable within context (soft failure)</c><c>IPv6 II <xref target="RFC7721" format="default"/>. Similarly, <xref target="RFC2460" fo
D</c> rmat="default"/> suggests the use of a global counter for the generation of Iden
<c>4</c><c>Uniqueness, monotonically increasing within context (hard fail tification values when the interoperability requirement of uniqueness per {IPv6
ure)</c><c>TCP ISN, TCP initial timestamp</c> Source Address, IPv6 Destination Address} could be achieved with other algorithm
</texttable> s that do not result in negative security and privacy implications <xref target=
"RFC7739" format="default"/>.</t>
<t>Finally, there are protocol implementations that simply fail to comply
with existing protocol specifications. For example, some popular operating syste
ms still fail to implement transport-protocol ephemeral port randomization, as r
ecommended in <xref target="RFC6056" format="default"/>, or TCP Initial Sequence
Number randomization, as recommended in <xref target="RFC9293"/>.</t>
<t> </section>
We note that Category #4 could be considered a generalized case of category #3, <section anchor="failure-severity" numbered="true" toc="default">
in which a monotonically increasing element is added to a stable (within context <name>Protocol Failure Severity</name>
) element, such that the resulting identifiers are monotonically increasing with <t><xref target="terminology" format="default"/> defines the concept of "f
in a specified context. That is, the same algorithm could be employed for both # ailure severity", along with two types of failure severities that we employ thro
3 and #4, given appropriate parameters. ughout this document: soft and hard.</t>
<t>Our analysis of the severity of a failure is performed from the point o
f view of the protocol in question. However, the corresponding severity on the u
pper protocol (or application) might not be the same as that of the protocol in
question. For example, a TCP connection that is aborted might or might not resul
t in a hard failure of the upper application, i.e., if the upper application can
establish a new TCP connection without any impact on the application, a hard fa
ilure at the TCP protocol may have no severity at the application layer. On the
other hand, if a hard failure of a TCP connection results in excessive degradati
on of service at the application layer, it will also result in a hard failure at
the application.
</t> </t>
</section> </section>
<section anchor="categorizing" numbered="true" toc="default">
<section title="Common Algorithms for Transient Numeric Identifier Generation" a <name>Categorizing Transient Numeric Identifiers</name>
nchor="common-algorithms"> <t>This section includes a non-exhaustive survey of transient numeric iden
<t>The following subsections describe some sample algorithms that can be employe tifiers, which are representative of all the possible combinations of interopera
d for generating transient numeric identifiers for each of the categories above, bility requirements and failure severities found in popular protocols of differe
while mitigating the vulnerabilities analyzed in <xref target="vulns"/> of this nt layers. Additionally, it proposes a number of categories that can accommodate
document.</t> these identifiers based on their interoperability requirements and their associ
ated failure severity (soft or hard).
<t>All of the variables employed in the algorithms of the following subsections </t>
are of "unsigned integer" type, except for the "retry" variable, that is of (sig <aside><t>NOTE: All other transient numeric identifiers that were analyz
ned) &quot;integer&quot; type.</t> ed as part of this effort could be accommodated into one of the existing categor
ies from <xref target="survey-table" format="default"/>.
<section title="Category #1: Uniqueness (soft failure)" anchor="cat-1-alg"> </t></aside>
<t>The requirement of uniqueness with a soft failure severity can be complied wi <table anchor="survey-table" align="center">
th a Pseudo-Random Number Generator (PRNG). <name>Survey of Transient Numeric Identifiers</name>
<list style="hanging"> <thead>
<t hangText="NOTE:"> <tr>
<vspace blankLines="0"/> <th align="center">Identifier</th>
Please see <xref target="RFC4086"/> regarding randomness requirements for securi <th align="center">Interoperability Requirements</th>
ty.</t> <th align="center">Failure Severity</th>
</list> </tr>
</thead>
<tbody>
<tr>
<td align="center">IPv6 ID</td>
<td align="center">Uniqueness (for IPv6 address pair)</td>
<td align="center">Soft/Hard (1)</td>
</tr>
<tr>
<td align="center">IPv6 IID</td>
<td align="center">Uniqueness (and stable within IPv6 prefix) (2)</t
d>
<td align="center">Soft (3)</td>
</tr>
<tr>
<td align="center">TCP ISN</td>
<td align="center">Monotonically increasing (4)</td>
<td align="center">Hard (4)</td>
</tr>
<tr>
<td align="center">TCP initial timestamp</td>
<td align="center">Monotonically increasing (5)</td>
<td align="center">Hard (5)</td>
</tr>
<tr>
<td align="center">TCP ephemeral port</td>
<td align="center">Uniqueness (for connection ID)</td>
<td align="center">Hard</td>
</tr>
<tr>
<td align="center">IPv6 Flow Label</td>
<td align="center">Uniqueness</td>
<td align="center">None (6)</td>
</tr>
<tr>
<td align="center">DNS ID</td>
<td align="center">Uniqueness</td>
<td align="center">None (7)</td>
</tr>
</tbody>
</table>
<t>NOTE:</t>
<ol type="(%d)" spacing="normal">
<li>While a single collision of IPv6 Identification (ID) values would si
mply lead to a single packet drop (and hence, a "soft" failure), repeated collis
ions at high data rates might result in self-propagating collisions of IPv6 IDs,
thus possibly leading to a hard failure <xref target="RFC4963" format="default"
/>.</li>
<li>While the interoperability requirements are simply that the Interfac
e Identifier results in a unique IPv6 address, for operational reasons, it is ty
pically desirable that the resulting IPv6 address (and hence, the corresponding
Interface Identifier) be stable within each network <xref target="RFC7217" forma
t="default"/> <xref target="RFC8064" format="default"/>.</li>
<li>While IPv6 Interface Identifiers must result in unique IPv6 addresse
s, IPv6 Duplicate Address Detection (DAD) <xref target="RFC4862" format="default
"/> allows for the detection of duplicate addresses, and hence, such Interface I
dentifier collisions can be recovered.</li>
<li>In theory, there are no interoperability requirements for TCP Initia
l Sequence Numbers (ISNs), since the TIME-WAIT state and TCP's "quiet time" conc
ept take care of old segments from previous incarnations of a connection. Howeve
r, a widespread optimization allows for a new incarnation of a previous connecti
on to be created if the ISN of the incoming SYN is larger than the last sequence
number seen in that direction for the previous incarnation of the connection. T
hus, monotonically increasing TCP ISNs allow for such optimization to work as ex
pected <xref target="RFC6528" format="default"/> and can help avoid connection-e
stablishment failures.</li>
<li>Strictly speaking, there are no interoperability requirements for th
e <strong>initial</strong> TCP timestamp employed by a TCP instance (i.e., the T
S Value (TSval) in a segment with the SYN bit set). However, some TCP implementa
tions allow a new incarnation of a previous connection to be created if the TSva
l of the incoming SYN is larger than the last TSval seen in that direction for t
he previous incarnation of the connection (please see <xref target="RFC6191" for
mat="default"/>). Thus, monotonically increasing TCP initial timestamps (across
connections to the same endpoint) allow for such optimization to work as expecte
d <xref target="RFC6191" format="default"/> and can help avoid connection-establ
ishment failures.</li>
<li>The IPv6 Flow Label <xref target="RFC6437" format="default"/>, along
with the IPv6 Source Address and the IPv6 Destination Address, is typically emp
loyed for load sharing <xref target="RFC7098" format="default"/>.
Reuse of a Flow Label value for the same set {Source Address, Destination Addres
s} would typically cause both flows to be multiplexed onto the same link. Howeve
r, as long as this does not occur deterministically, it will not result in any n
egative implications.</li>
<li>DNS IDs are employed, together with the IP Source Address, the IP De
stination Address, the transport-protocol Source Port, and the transport-protoco
l Destination Port, to match DNS requests and responses. However, since an imple
mentation knows which DNS requests were sent for that set of {IP Source Address,
IP Destination Address, transport-protocol Source Port, transport-protocol Dest
ination Port, DNS ID}, a collision of DNS IDs would result, if anything, in a sm
all performance penalty (the response would nevertheless be discarded when it is
found that it does not answer the query sent in the corresponding DNS query).</
li>
</ol>
<t>Based on the survey above, we can categorize identifiers as follows:</t
>
<table anchor="cat-table" align="center">
<name>Identifier Categories</name>
<thead>
<tr>
<th align="center">Cat #</th>
<th align="center">Category</th>
<th align="center">Sample Numeric IDs</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1</td>
<td align="center">Uniqueness (soft failure)</td>
<td align="center">IPv6 Flow L., DNS ID</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">Uniqueness (hard failure)</td>
<td align="center">IPv6 ID, TCP ephemeral port</td>
</tr>
<tr>
<td align="center">3</td>
<td align="center">Uniqueness, stable within context (soft failure)<
/td>
<td align="center">IPv6 IID</td>
</tr>
<tr>
<td align="center">4</td>
<td align="center">Uniqueness, monotonically increasing within conte
xt (hard failure)</td>
<td align="center">TCP ISN, TCP initial timestamp</td>
</tr>
</tbody>
</table>
<t>
We note that Category #4 could be considered a generalized case of Category #3,
in which a monotonically increasing element is added to a stable (within context
) element, such that the resulting identifiers are monotonically increasing with
in a specified context. That is, the same algorithm could be employed for both #
3 and #4, given appropriate parameters.
</t> </t>
</section>
<t>While most systems provide access to a PRNG, many of such PRNG implementation <section anchor="common-algorithms" numbered="true" toc="default">
s are not cryptographically secure, and therefore might be statistically biased <name>Common Algorithms for Transient Numeric Identifier Generation</name>
or subject to adversarial influence. For example, ISO C <xref target="C11"/> ran <t>The following subsections describe some sample algorithms that can be e
d(3) implementations are not cryptographically secure. mployed for generating transient numeric identifiers for each of the categories
<list style="hanging"> above while mitigating the vulnerabilities analyzed in <xref target="vulns" form
<t hangText="NOTE:"> at="default"/> of this document.</t>
<vspace blankLines="0"/> <t>All of the variables employed in the algorithms of the following subsec
Section 7.1 ("Uniform Deviates") of <xref target="Press1992"/> discusses the und tions are of "unsigned integer" type, except for the "retry" variable, which is
erlying issues affecting ISO C <xref target="C11"/> rand(3) implementations. of (signed) "integer" type.</t>
<section anchor="cat-1-alg" numbered="true" toc="default">
<name>Category #1: Uniqueness (Soft Failure)</name>
<t>The requirement of uniqueness with a soft failure severity can be com
plied with a Pseudorandom Number Generator (PRNG).
</t> </t>
</list> <aside><t>NOTE: Please see <xref target="RFC4086" format="default"/> r
egarding randomness requirements for security.</t></aside>
<t>While most systems provide access to a PRNG, many of such PRNG implem
entations are not cryptographically secure and therefore might be statistically
biased or subject to adversarial influence. For example, ISO C <xref target="C11
" format="default"/> rand(3) implementations are not cryptographically secure.
</t> </t>
<aside><t>NOTE: Section 7.1 ("Uniform Deviates") of <xref target="Pres
s1992" format="default"/> discusses the underlying issues affecting ISO C <xref
target="C11" format="default"/> rand(3) implementations.
</t></aside>
<t>On the other hand, a number of systems provide an interface to a Cr
yptographically Secure PRNG (CSPRNG) <xref target="RFC4086" format="default"/> <
xref target="RFC8937" format="default"/>, which guarantees high entropy, unpredi
ctability, and good statistical distribution of the random values generated. Fo
r example, GNU/Linux's CSPRNG implementation is available via the getentropy(3)
interface <xref target="GETENTROPY" format="default"/>, while OpenBSD's CSPRNG i
mplementation is available via the arc4random(3) and arc4random_uniform(3) inter
faces <xref target="ARC4RANDOM" format="default"/>. Where available, these CSPRN
Gs should be preferred over, e.g., POSIX <xref target="POSIX" format="default"/>
random(3) or ISO C <xref target="C11" format="default"/> rand(3) implementation
s.</t>
<t>In scenarios where a CSPRNG is not readily available to select transi
ent numeric identifiers of Category #1, a security and privacy assessment of emp
loying a regular PRNG should be performed, supporting the implementation decisio
n.
<t>On the other hand, a number of systems provide an interface to a Cryptographi
cally Secure PRNG (CSPRNG) <xref target="RFC8937"/> <xref target="RFC4086"/>, wh
ich guarantees high entropy, unpredictability, and good statistical distribution
of the random values generated. For example, GNU/Linux's CSPRNG implementation
is available via the getentropy(3) interface <xref target="GETENTROPY"/>, while
OpenBSD's CSPRNG implementation is available via the arc4random(3) and arc4rando
m_uniform(3) interfaces <xref target="ARC4RANDOM"/>. Where available, these CSPR
NGs should be preferred over e.g. POSIX <xref target="POSIX"/> random(3) or ISO
C <xref target="C11"/> rand(3) implementations.</t>
<t>In scenarios where a CSPRNG is not readily available to select transient nume
ric identifiers of Category #1, a security and privacy assessment of employing a
regular PRNG should be performed, supporting the implementation decision.
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
<xref target="Aumasson2018"/>, <xref target="Press1992"/>, and <xref target="Knu
th1983"/>, discuss theoretical and practical aspects of pseudorandom numbers gen
eration, and provide guidance on how to evaluate PRNGs.</t>
</list>
</t> </t>
<aside><t>NOTE: <xref target="Aumasson2018" format="default"/>, <xref
<t>We note that since the premise is that collisions of transient numeric identi target="Press1992" format="default"/>, and <xref target="Knuth1983" format="defa
fiers of this category only leads to soft failures, in many cases, the algorithm ult"/> discuss theoretical and practical aspects of pseudorandom number generati
might not need to check the suitability of a selected identifier (i.e., the sui on and provide guidance on how to evaluate PRNGs.</t></aside>
table_id() function, described below, could always return "true").</t> <t>We note that, since the premise is that collisions of transient numer
ic identifiers of this category only lead to soft failures, in many cases, the a
<t>In scenarios where e.g. simultaneous use of a given numeric ID is undesirable lgorithm might not need to check the suitability of a selected identifier (i.e.,
and the implementation detects such condition, an implementation may opt to sel the suitable_id() function, described below, could always return "true").</t>
ect the next available identifier in the same sequence, or select another random <t>In scenarios where, e.g., simultaneous use of a given numeric identif
number. <xref target="simple-randomization"/> is an implementation of the forme ier is undesirable and an implementation detects such condition, the implementat
r strategy, while <xref target="simple-randomization2"/> is an implementation of ion may opt to select the next available identifier in the same sequence or sele
the later. Typically, the algorithm in <xref target="simple-randomization2"/> r ct another random number. <xref target="simple-randomization" format="default"/>
esults in a more uniform distribution of the generated transient numeric identif is an implementation of the former strategy, while <xref target="simple-randomi
iers. However, for transient numeric identifiers where an implementation typical zation2" format="default"/> is an implementation of the latter. Typically, the a
ly keeps local state about unsuitable/used identifiers, the algorithm in <xref lgorithm in <xref target="simple-randomization2" format="default"/> results in a
target="simple-randomization2"/> may require many more iterations than the algor more uniform distribution of the generated transient numeric identifiers. Howev
ithm in <xref target="simple-randomization"/> to generate a suitable transient n er, for transient numeric identifiers where an implementation typically keeps lo
umeric identifier. This will usually be affected by the current usage ratio of t cal state about unsuitable/used identifiers, the algorithm in <xref target="simp
ransient numeric identifiers (i.e., number of numeric identifiers considered sui le-randomization2" format="default"/> may require many more iterations than the
table / total number of numeric identifiers) and other parameters. Therefore, in algorithm in <xref target="simple-randomization" format="default"/> to generate
such cases many implementations tend to prefer the algorithm in <xref target="s a suitable transient numeric identifier. This will usually be affected by the cu
imple-randomization"/> over the algorithm in <xref target="simple-randomization2 rrent usage ratio of transient numeric identifiers (i.e., the number of numeric
"/>. identifiers considered suitable / total number of numeric identifiers) and other
parameters. Therefore, in such cases, many implementations tend to prefer the a
lgorithm in <xref target="simple-randomization" format="default"/> over the algo
rithm in <xref target="simple-randomization2" format="default"/>.
</t> </t>
<section anchor="simple-randomization" numbered="true" toc="default">
<section title="Simple Randomization Algorithm" anchor="simple-randomization"> <name>Simple Randomization Algorithm</name>
<sourcecode type="c"><![CDATA[
<t>
<figure><artwork>
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
next_id = min_id + (random() % id_range); next_id = min_id + (random() % id_range);
retry = id_range; retry = id_range;
do { do {
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
skipping to change at line 315 skipping to change at line 287
next_id = min_id; next_id = min_id;
} else { } else {
next_id++; next_id++;
} }
retry--; retry--;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
</artwork> ]]></sourcecode>
</figure> <t>NOTE:</t>
<t indent="3">random() is a PRNG that returns a pseudorandom unsigned i
</t> nteger number of appropriate size. Beware that "adapting" the length of the outp
<!-- FreeBSD/OpenBSD: in_pcb.c, Linux: tcp_ipv4.c(+grsecurity) --> ut of random() with a modulo operator (e.g., C language's "%") may change the di
stribution of the PRNG. To preserve a uniform distribution, the rejection sampli
<t> ng technique <xref target="Romailler2020" format="default"/> can be used.</t>
<list style="hanging"> <t indent="3">suitable_id() is a function that checks, if possible a
<t hangText="NOTE:"> nd desirable, whether a candidate numeric identifier is suitable (e.g., whether
<vspace blankLines="0"/> it is in use or has been recently employed). Depending on how/where the numeric
random() is a PRNG that returns a pseudo-random unsigned integer number of appro identifier is used, it may or may not be possible (or even desirable) to check w
priate size. <!-- Note that the output needs to be unpredictable, and typical im hether the numeric identifier is suitable.
plementations of the POSIX random() function do not necessarily meet this requir
ement. See <xref target="RFC4086"/> for randomness requirements for security. --
>Beware that "adapting" the length of the output of random() with a modulo opera
tor (e.g., C-language's "%") may change the distribution of the PRNG. To preserv
e a uniform distribution, the rejection sampling technique <xref target="Romaill
er2020"/> can be used.</t>
<t>
The function suitable_id() can check, when possible and desirable, whether a sel
ected transient numeric identifier is suitable (e.g. it is not already in use).
Depending on how/where the numeric identifier is used, it may or may not be poss
ible (or even desirable) to check whether the numeric identifier is in use (or w
hether it has been recently employed). When an identifier is found to be unsuita
ble, this algorithm selects the next available numeric identifier in sequence.
</t> </t>
<t>Even when this algorithm selects numeric IDs randomly, it is biased towards t <t indent="3">All the variables (in this algorithm and all the other
he first available numeric ID after a sequence of unavailable numeric IDs. For e s algorithms discussed in this document) are unsigned integers.</t>
xample, if this algorithm is employed for transport protocol ephemeral port rand
omization <xref target="RFC6056"/> and the local list of unsuitable port numbers
(e.g., registered port numbers that should not be used for ephemeral ports) is
significant, an attacker may actually have a significantly better chance of gues
sing a port number.
</t>
<t> <t>When an identifier is found to be unsuitable, this algorithm sele
All the variables (in this and all the algorithms discussed in this document) ar cts the next available numeric identifier in sequence. Thus, even when this algo
e unsigned integers.</t> rithm selects numeric identifiers randomly, it is biased towards the first avail
</list> able numeric identifier after a sequence of unavailable numeric identifiers. For
example, if this algorithm is employed for transport-protocol ephemeral port ra
ndomization <xref target="RFC6056" format="default"/> and the local list of unsu
itable port numbers (e.g., registered port numbers that should not be used for e
phemeral ports) is significant, an attacker may actually have a significantly be
tter chance of guessing an ephemeral port number.
</t> </t>
<t>Assuming the randomness requirements for the PRNG are met (see <xref target=" <t>Assuming the randomness requirements for the PRNG are met (see <xre
RFC4086"/>), this algorithm does not suffer from any of the issues discussed in f target="RFC4086" format="default"/>), this algorithm does not suffer from any
<xref target="vulns"/>.</t> of the issues discussed in <xref target="vulns" format="default"/>.</t>
</section> </section>
<section anchor="simple-randomization2" numbered="true" toc="default">
<section title="Another Simple Randomization Algorithm" anchor="simple-randomiza <name>Another Simple Randomization Algorithm</name>
tion2"> <t>The following pseudocode illustrates another algorithm for selectin
<t>The following pseudo-code illustrates another algorithm for selecting a rando g a random transient numeric identifier where, in the event a selected identifie
m transient numeric identifier which, in the event a selected identifier is foun r is found to be unsuitable (e.g., already in use), another identifier is random
d to be unsuitable (e.g., already in use), another identifier is randomly select ly selected:</t>
ed:</t> <sourcecode type="c"><![CDATA[
<t>
<figure>
<artwork>
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
retry = id_range; retry = id_range;
do { do {
next_id = min_id + (random() % id_range); next_id = min_id + (random() % id_range);
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry--; retry--;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
]]></sourcecode>
</artwork> <t>NOTE:</t>
</figure> <t indent="3">random() is a PRNG that returns a pseudorandom unsigned i
</t> nteger number of appropriate size. Beware that "adapting" the length of the outp
ut of random() with a modulo operator (e.g., C language's "%") may change the di
<t>This algorithm might be unable to select a transient numeric identifier (i.e. stribution of the PRNG. To preserve a uniform distribution, the rejection sampli
, return "ERROR") even if there are suitable identifiers available, in cases whe ng technique <xref target="Romailler2020" format="default"/> can be used.</t>
re a large number of identifiers are found to be unsuitable (e.g. "in use").</t> <t indent="3">suitable_id() is a function that checks, if possible a
nd desirable, whether a candidate numeric identifier is suitable (e.g., if it is
<t>The same considerations from <xref target="simple-randomization"/> with respe not already in use). Depending on how/where the numeric identifier is used, it
ct to the properties of random() and the adaptation of its output length apply t may or may not be possible (or even desirable) to check whether the numeric iden
o this algorithm.</t> tifier is in use (or whether it has been recently employed).
<t>Assuming the randomness requirements for the PRNG are met (see <xref target="
RFC4086"/>), this algorithm does not suffer from any of the issues discussed in
<xref target="vulns"/>.</t>
</section>
</section>
<section title="Category #2: Uniqueness (hard failure)" anchor="cat-2-alg">
<t>One of the most trivial approaches for generating unique transient numeric id
entifier (with a hard failure severity) is to reduce the identifier reuse freque
ncy by generating the numeric identifiers with a monotonically-increasing functi
on (e.g. linear). As a result, any of the algorithms described in <xref target="
cat-4-alg"/> ("Category #4: Uniqueness, monotonically increasing within context
(hard failure)") can be readily employed for complying with the requirements of
this transient numeric identifier category.
</t> </t>
<t>In cases where suitability (e.g. uniqueness) of the selected identifiers can be definitely assessed by the local system, any of the algorithms described in < xref target="cat-1-alg"/> ("Category #1: Uniqueness (soft failure)") can be read ily employed for complying with the requirements of this numeric identifier cate gory.</t> <t>When an identifier is found to be unsuitable, this algorithm select s another random numeric identifier. Thus, this algorithm might be unable to sel ect a transient numeric identifier (i.e., return "ERROR"), even if there are sui table identifiers available, in cases where a large number of identifiers are fo und to be unsuitable (e.g., "in use").</t>
<t> <t>Assuming the randomness requirements for the PRNG are met (see <xre
<list style="hanging"> f target="RFC4086" format="default"/>), this algorithm does not suffer from any
<t hangText="NOTE:"> of the issues discussed in <xref target="vulns" format="default"/>.</t>
<vspace blankLines="0"/> </section>
In the case of e.g. TCP ephemeral ports or TCP ISNs, a transient numeric identif </section>
ier that might seem suitable from the perspective of the local system, might act <section anchor="cat-2-alg" numbered="true" toc="default">
ually be unsuitable from the perspective of the remote system (e.g., because the <name>Category #2: Uniqueness (Hard Failure)</name>
re is state associated with the selected identifier at the remote system). There <t>One of the most trivial approaches for generating a unique transient
fore, in such cases it is not possible to employ the algorithms from <xref targe numeric identifier (with a hard failure severity) is to reduce the identifier re
t="cat-1-alg"/> ("Category #1: Uniqueness (soft failure)"). use frequency by generating the numeric identifiers with a monotonically increas
</t> ing function (e.g., linear). As a result, any of the algorithms described in <xr
</list> ef target="cat-4-alg" format="default"/> ("Category #4: Uniqueness, Monotonicall
y Increasing within Context (Hard Failure)") can be readily employed for complyi
ng with the requirements of this transient numeric identifier category.
</t> </t>
<t>In cases where suitability (e.g., uniqueness) of the selected identif
</section> iers can be definitely assessed by the local system, any of the algorithms descr
ibed in <xref target="cat-1-alg" format="default"/> ("Category #1: Uniqueness (S
<section title="Category #3: Uniqueness, stable within context (soft failure)" a oft Failure)") can be readily employed for complying with the requirements of th
nchor="cat-3-alg"> is numeric identifier category.</t>
<t>The goal of the following algorithm is to produce identifiers that are stable <aside><t>NOTE: In the case of, e.g., TCP ephemeral ports or TCP ISNs, a
for a given context (identified by &quot;CONTEXT&quot;), but that change when t transient numeric identifier that might seem suitable from the perspective of t
he aforementioned context changes. <!--For example, if the identifiers being gen he local system might actually be unsuitable from the perspective of the remote
erated must be unique for each {src IP, dst IP} set, then each possible combinat system (e.g., because there is state associated with the selected identifier at
ion of {src IP, dst IP} should have a corresponding "next_id" value. --> the remote system). Therefore, in such cases, it is not possible to employ the a
lgorithms from <xref target="cat-1-alg" format="default"/> ("Category #1: Unique
ness (Soft Failure)").
</t></aside>
</section>
<section anchor="cat-3-alg" numbered="true" toc="default">
<name>Category #3: Uniqueness, Stable within Context (Soft Failure)</nam
e>
<t>The goal of the following algorithm is to produce identifiers that ar
e stable for a given context (identified by "CONTEXT") but that change when the
aforementioned context changes.
</t> </t>
<t>In order to avoid storing the transient numeric identifiers computed
<t><!--Keeping one value for each possible "context" may in many cases be consid for each CONTEXT in memory, the following algorithm employs a calculated techniq
ered too onerous in terms of memory requirements. -->In order to avoid storing i ue (as opposed to keeping state in memory) to generate a stable transient numeri
n memory the transient numeric identifiers computed for each CONTEXT, the follow c identifier for each given context.
ing algorithm employs a calculated technique (as opposed to keeping state in mem
ory) to generate a stable transient numeric identifier for each given context.
</t> </t>
<sourcecode type="c"><![CDATA[
<t>
<figure><artwork>
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
retry = 0; retry = 0;
do { do {
offset = F(CONTEXT, retry, secret_key); offset = F(CONTEXT, retry, secret_key);
next_id = min_id + (offset % id_range); next_id = min_id + (offset % id_range);
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry++; retry++;
} while (retry &lt;= MAX_RETRIES); } while (retry <= MAX_RETRIES);
return ERROR; return ERROR;
]]></sourcecode>
</artwork> <t>NOTE:</t>
</figure> <t indent="3">CONTEXT is the concatenation of all the elements that de
</t> fine a given context.</t>
<!-- <t indent="3">F() is a pseudorandom function (PRF). It must not be compu
<t>F() must be a cryptographically-secure hash function (e.g. SHA-256 <xref targ table from the outside (without knowledge of the secret key). F() must also be d
et="FIPS-SHS"/>), that is computed over the concatenation of its arguments. ifficult to reverse, such that it resists attempts to obtain the secret key, eve
n when given samples of the output of F() and knowledge or control of the other
input parameters. F() should produce an output of at least as many bits as requi
red for the transient numeric identifier. SipHash-2-4 (128-bit key, 64-bit outpu
t) <xref target="SipHash" format="default"/> and BLAKE3 (256-bit key, arbitrary-
length output) <xref target="BLAKE3" format="default"/> are two possible options
for F(). Alternatively, F() could be implemented with a keyed hash message auth
entication code (HMAC) <xref target="RFC2104" format="default"/>. HMAC-SHA-256 <
xref target="FIPS-SHS" format="default"/> would be one possible option for such
implementation alternative. Note: Use of HMAC-MD5 <xref target="RFC1321" format=
"default"/> or HMAC-SHA1 <xref target="FIPS-SHS" format="default"/> are not reco
mmended for F() <xref target="RFC6151" format="default"/> <xref target="RFC6194"
format="default"/>. The result of F() is no more secure than the secret key, an
d therefore, "secret_key" must be unknown to the attacker and must be of a reaso
nable length. "secret_key" must remain stable for a given CONTEXT, since otherwi
se, the numeric identifiers generated by this algorithm would not have the desir
ed stability properties (i.e., stable for a given CONTEXT). In most cases, "secr
et_key" should be selected with a PRNG (see <xref target="RFC4086" format="defau
lt"/> for recommendations on choosing secrets) at an appropriate time and stored
in stable or volatile storage (as necessary) for future use.
</t>
<t>In this algorithm, the function F() provides a stateless and stable per-CONTE XT offset, where CONTEXT is the concatenation of all the elements that define th e given context. <t indent="3">suitable_id() checks whether a candidate numeric identifie r has suitable uniqueness properties. </t>
<list style="hanging"> <t>In this algorithm, the function F() provides a stateless and stable per-CONTE
<t>For example, if this algorithm is expected to produce IPv6 IIDs that are uniq XT offset, where CONTEXT is the concatenation of all the elements that define th
ue per network interface and SLAAC autoconfiguration prefix, the CONTEXT should e given context.
be the concatenation of e.g. the network interface index and the SLAAC autoconfi
guration prefix (please see <xref target="RFC7217"/> for an implementation of th
is algorithm for generation of stable IPv6 IIDs).
</t> </t>
</list> <t>For example, if this algorithm is expected to produce IPv6 IIDs tha t are unique per network interface and Stateless Address Autoconfiguration (SLAA C) prefix, CONTEXT should be the concatenation of, e.g., the network interface i ndex and the SLAAC autoconfiguration prefix (please see <xref target="RFC7217" f ormat="default"/> for an implementation of this algorithm for generation of stab le IPv6 addresses).
</t> </t>
<t>F() is a pseudorandom function (PRF). It must not be computable from the outs <t>The result of F() is stored in the variable "offset", which may take
ide (without knowledge of the secret key). F() must also be difficult to reverse any value within the storage type range, since we are restricting the resulting
, such that it resists attempts to obtain the secret_key, even when given sample identifier to be in the range [min_id, max_id] in a similar way as in the algori
s of the output of F() and knowledge or control of the other input parameters. F thm described in <xref target="simple-randomization" format="default"/>.</t>
() should produce an output of at least as many bits as required for the transie <t>As noted above, suitable_id() checks whether a candidate numeric iden
nt numeric identifier. SipHash-2-4 (128-bit key, 64-bit output) <xref target="Si tifier has suitable uniqueness properties. Collisions (i.e., an identifier that
pHash"/> and BLAKE3 (256-bit key, arbitrary-length output) <xref target="BLAKE3" is not unique) are recovered by incrementing the "retry" variable and recomputin
/> are two possible options for F(). Alternatively, F() could be implemented wit g F(), up to a maximum of MAX_RETRIES times. However, recovering from collisions
h a keyed-hash message authentication code (HMAC) <xref target="RFC2104"/>. HMAC will usually result in identifiers that fail to remain constant for the specifi
-SHA-256 <xref target="FIPS-SHS"/> would be one possible option for such impleme ed context. This is normally acceptable when the probability of collisions is sm
ntation alternative. Note: Use of HMAC-MD5 <xref target="RFC1321"/> or HMAC-SHA1 all, as in the case of, e.g., IPv6 IIDs resulting from SLAAC <xref target="RFC72
<xref target="FIPS-SHS"/> are not recommended for F() <xref target="RFC6151"/> 17" format="default"/> <xref target="RFC8981" format="default"/>.</t>
<xref target="RFC6194"/>.</t> <t>For obvious reasons, the transient numeric identifiers generated with
this algorithm allow for network activity correlation and fingerprinting within
<t>The result of F() is no more secure than the secret key, and therefore 'secre "CONTEXT". However, this is essentially a design goal of this category of trans
t_key' must be unknown to the attacker, and must be of a reasonable length. 'sec ient numeric identifiers.</t>
ret_key' must remain stable for a given CONTEXT, since otherwise the numeric ide </section>
ntifiers generated by this algorithm would not have the desired stability proper <section anchor="cat-4-alg" numbered="true" toc="default">
ties (i.e., stable for a given CONTEXT). In most cases, 'secret_key' should be s <name>Category #4: Uniqueness, Monotonically Increasing within Context (
elected with a PRNG (see <xref target="RFC4086"/> for recommendations on choosin Hard Failure)</name>
g secrets) at an appropriate time, and stored in stable or volatile storage (as <section anchor="per-context-counter" numbered="true" toc="default">
necessary) for future use. <name>Per-Context Counter Algorithm</name>
</t> <t>One possible way of selecting unique monotonically increasing ident
ifiers (per context) is to employ a per-context counter. Such an algorithm could
<t>The result of F() is stored in the variable 'offset', which may take any valu be described as follows:</t>
e within the storage type range, since we are restricting the resulting identifi <sourcecode type="c"><![CDATA[
er to be in the range [min_id, max_id] in a similar way as in the algorithm desc
ribed in <xref target="simple-randomization"/>.</t>
<t>suitable_id() checks whether the candidate identifier has suitable uniqueness
properties. Collisions (i.e., an identifier that is not unique) are recovered b
y incrementing the 'retry' variable and recomputing F(), up to a maximum of MAX_
RETRIES times. However, recovering from collisions will usually result in identi
fiers that fail to remain constant for the specified context. This is normally a
cceptable when the probability of collisions is small, as in the case of e.g. IP
v6 IIDs resulting from SLAAC <xref target="RFC7217"/> <xref target="RFC8981"/>.<
/t>
<t>For obvious reasons, the transient numeric identifiers generated with this al
gorithm allow for network activity correlation and fingerprinting within "CONTEX
T". However, this is essentially a design goal of this category of transient num
eric identifiers.</t>
</section>
<section title="Category #4: Uniqueness, monotonically increasing within context
(hard failure)" anchor="cat-4-alg">
<section title="Per-context Counter Algorithm" anchor="per-context-counter">
<t>One possible way of selecting unique monotonically-increasing identifiers (pe
r context) is to employ a per-context counter. Such an algorithm could be descri
bed as follows:</t>
<t>
<figure>
<artwork>
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
retry = id_range; retry = id_range;
id_inc = increment() % id_range; id_inc = increment() % id_range;
if( (next_id = lookup_counter(CONTEXT)) == ERROR){ if( (next_id = lookup_counter(CONTEXT)) == ERROR){
next_id = min_id + random() % id_range; next_id = min_id + random() % id_range;
} }
skipping to change at line 490 skipping to change at line 420
if (suitable_id(next_id)){ if (suitable_id(next_id)){
store_counter(CONTEXT, next_id); store_counter(CONTEXT, next_id);
return next_id; return next_id;
} }
retry = retry - id_inc; retry = retry - id_inc;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
</artwork> ]]></sourcecode>
</figure> <t>NOTE:</t>
</t> <t indent="3">CONTEXT is the concatenation of all the elements that de
<t> fine a given context.</t>
<list style="hanging">
<t hangText="NOTES:">
<vspace blankLines="0"/>
increment() returns a small integer that is employed to increment the current co
unter value to obtain the next transient numeric identifier. This value must be
much smaller than the number of possible values for the numeric IDs (i.e., "id_r
ange"). Most implementations of this algorithm employ a constant increment of 1.
Using a value other than 1 can help mitigate some information leakages (please
see below), at the expense of a possible increase in the numeric ID reuse freque
ncy.</t>
<t>The code above makes sure that the increment employed in the algorithm (id_in
c) is always smaller than the number of possible values for the numeric IDs (i.e
., "max_id - min_d + 1"). However, as noted above, this value must also be much
smaller than the number of possible values for the numeric IDs.</t>
<t>lookup_counter() is a function that returns the current counter for a given c
ontext, or an error condition if that counter does not exist.</t>
<t>store_counter() is a function that saves a counter value for a given context.
</t>
<t>suitable_id() is a function that checks whether the resulting identifier is a
cceptable (e.g., whether it is not already in use, etc.).
</t>
</list>
</t>
<t>Essentially, whenever a new identifier is to be selected, the algorithm check <t indent="3">increment() returns a small integer that is employed t
s whether a counter for the corresponding context exists. If does, the value of o increment the current counter value to obtain the next transient numeric ident
such counter is incremented to obtain the new transient numeric identifier, and ifier. This value must be larger than or equal to 1, and much smaller than the n
the counter is updated. If no counter exists for such context, a new counter is umber of possible values for the numeric identifiers (i.e., "id_range"). Most im
created and initialized to a random value, and used as the selected transient nu plementations of this algorithm employ a constant increment of 1. Using a value
meric identifier. This algorithm produces a per-context counter, which results i other than 1 can help mitigate some information leakages (please see below) at t
n one monotonically-increasing function for each context. Since each counter is he expense of a possible increase in the numeric identifier reuse frequency. The
initialized to a random value, the resulting values are unpredictable by an off- code above makes sure that the increment employed in the algorithm (id_inc) is
path attacker. always smaller than the number of possible values for the numeric identifiers (i
</t> .e., "max_id - min_d + 1"). However, as noted above, this value must also be muc
h smaller than the number of possible values for the numeric identifiers.</t>
<t indent="3">lookup_counter() is a function that returns the curren
t counter for a given context or an error condition if that counter does not exi
st.</t>
<t indent="3">random() is a PRNG that returns a pseudorandom unsigned i
nteger number of appropriate size. Beware that "adapting" the length of the outp
ut of random() with a modulo operator (e.g., C language's "%") may change the di
stribution of the PRNG. To preserve a uniform distribution, the rejection sampli
ng technique <xref target="Romailler2020" format="default"/> can be used.</t>
<t>The choice of id_inc has implications on both the security and privacy proper <t indent="3">store_counter() is a function that saves a counter val
ties of the resulting identifiers, but also on the corresponding interoperabilit ue for a given context.</t>
y properties. On one hand, minimizing the increments generally minimizes the ide
ntifier reuse frequency, albeit at increased predictability. On the other hand,
if the increments are randomized, predictability of the resulting identifiers is
reduced, and the information leakage produced by global constant increments is
mitigated. However, using larger increments than necessary can result in higher
numeric ID reuse frequency.
</t>
<t>This algorithm has the following drawbacks: <t indent="3">suitable_id() checks whether a candidate numeric identifie
<list style="symbols"> r has suitable uniqueness properties. </t>
<t>It requires an implementation to store each per-CONTEXT counter in memory. If
, as a result of resource management, the counter for a given context must be re
moved, the last transient numeric identifier value used for that context will be
lost. Thus, if subsequently an identifier needs to be generated for the same c
ontext, the corresponding counter will need to be recreated and reinitialized to
a random value, thus possibly leading to reuse/collision of numeric identifiers
.
</t>
<t> <t>Essentially, whenever a new identifier is to be selected, the algor
Keeping one counter for each possible "context" may in some cases be considered ithm checks whether a counter for the corresponding context exists. If it does,
too onerous in terms of memory requirements. the value of such counter is incremented to obtain the new transient numeric ide
ntifier, and the counter is updated. If no counter exists for such context, a ne
w counter is created and initialized to a random value and used as the selected
transient numeric identifier. This algorithm produces a per-context counter, whi
ch results in one monotonically increasing function for each context. Since each
counter is initialized to a random value, the resulting values are unpredictabl
e by an off-path attacker.
</t> </t>
<t>The choice of id_inc has implications on both the security and priv
<!-- acy properties of the resulting identifiers and also on the corresponding intero
<t>An implementation may map more than one context to the same counter, such the perability properties. On one hand, minimizing the increments generally minimize
amount of memory required to store counters is reduced, at the expense of a pos s the identifier reuse frequency, albeit at increased predictability. On the oth
sible unnecessary increase in the numeric identifier reuse frequency. In such ca er hand, if the increments are randomized, predictability of the resulting ident
ses, if the identifiers are predictable by the destination system (in case the d ifiers is reduced, and the information leakage produced by global constant incre
estination host represents the "context"), a vulnerable host might possibly leak ments is mitigated. However, using larger increments than necessary can result i
to third parties the identifiers used by other hosts to send traffic to it (i.e n higher numeric identifier reuse frequency.
., a vulnerable Host B could leak to Host C the identifier values that Host A is
using to send packets to Host B). Appendix A of <xref target="RFC7739"/> descri
bes one possible scenario for such leakage in detail. Employing small random num
bers for the increments (i.e., for increment() function) may help mitigate this
kind of information leakage.
</t> </t>
</list> <t>This algorithm has the following drawbacks:
</t> </t>
<ul spacing="normal">
<li>It requires an implementation to store each per-context counter
in memory. If, as a result of resource management, the counter for a given conte
xt must be removed, the last transient numeric identifier value used for that co
ntext will be lost. Thus, if an identifier subsequently needs to be generated f
or the same context, the corresponding counter will need to be recreated and rei
nitialized to a random value, thus possibly leading to reuse/collision of numeri
c identifiers.
</li>
<li>
Keeping one counter for each possible "context" may in some cases be considered
too onerous in terms of memory requirements.
</li>
<t>Otherwise, the identifiers produced by this algorithm do not suffer from the </ul>
other issues discussed in <xref target="vulns"/>.</t> <t>Otherwise, the identifiers produced by this algorithm do not suffer
</section> from the other issues discussed in <xref target="vulns" format="default"/>.</t>
</section>
<section title="Simple PRF-Based Algorithm" anchor="simple-hash"> <section anchor="simple-hash" numbered="true" toc="default">
<t>The goal of this algorithm is to produce monotonically-increasing transient n <name>Simple PRF-Based Algorithm</name>
umeric identifiers (for each given context), with a randomized initial value. Fo <t>The goal of this algorithm is to produce monotonically increasing t
r example, if the identifiers being generated must be monotonically-increasing f ransient numeric identifiers (for each given context) with a randomized initial
or each {IP Source Address, IP Destination Address} set, then each possible comb value. For example, if the identifiers being generated must be monotonically inc
ination of {IP Source Address, IP Destination Address} should have a separate mo reasing for each {Source Address, Destination Address} set, then each possible c
notonically-increasing sequence, that starts at a different random value. ombination of {Source Address, Destination Address} should have a separate monot
onically increasing sequence that starts at a different random value.
</t> </t>
<t>Instead of maintaining a per-context counter (as in the algorithm f
<t>Instead of maintaining a per-context counter (as in the algorithm from <xref rom <xref target="per-context-counter" format="default"/>), the following algori
target="per-context-counter"/>), the following algorithm employs a calculated te thm employs a calculated technique to maintain a random offset for each possible
chnique to maintain a random offset for each possible context. context.
</t> </t>
<sourcecode type="c"><![CDATA[
<t>
<figure><artwork>
/* Initialization code */ /* Initialization code */
counter = 0; counter = 0;
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
id_inc = increment() % id_range; id_inc = increment() % id_range;
offset = F(CONTEXT, secret_key); offset = F(CONTEXT, secret_key);
retry = id_range; retry = id_range;
skipping to change at line 563 skipping to change at line 478
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry = retry - id_inc; retry = retry - id_inc;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
]]></sourcecode>
<t>NOTE:</t>
<t indent="3">CONTEXT is the concatenation of all the elements that de
fine a given context. For example, if this algorithm is expected to produce iden
tifiers that are monotonically increasing for each set {Source Address, Destinat
ion Address}, CONTEXT should be the concatenation of Source Address and Destinat
ion Address.</t>
</artwork> <t indent="3">increment() has the same properties and requirements as
</figure> those specified for increment() in <xref target="per-context-counter" format="de
</t> fault"/>.</t>
<t indent="3">F() is a PRF, with the same properties as those specifie
<!-- d for F() in <xref target="cat-3-alg" format="default"/>.</t>
<t>
The function F() should be a cryptographically-secure hash function (e.g. SH
A-256 <xref target="FIPS-SHS"/>). CONTEXT is the concatenation of all the elemen
ts that define a given context. For example, if this algorithm is expected to pr
oduce identifiers that are monotonically-increasing for each set (Source IP Addr
ess, Destination IP Address), CONTEXT should be the concatenation of these two I
P addresses.
</t>
<!-- Nuevo:
<t>F() is a pseudorandom function (PRF) that must not be computable from the out
side (without knowledge of the secret key). F() must also be difficult to revers
e, such that it resists attempts to obtain the secret_key, even when given sampl
es of the output of F() and knowledge or control of the other input parameters.
F() should produce an output of at least as many bits as required for the transi
ent numeric identifier. F() could be the result of applying a cryptographic hash
over an encoded version of the function parameters. While this document does n
ot recommend a specific mechanism for encoding the function parameters (or a spe
cific cryptographic hash function), a cryptographically robust construction will
ensure that the mapping from parameters to the hash function input is an inject
ive map, as might be attained by using fixed-width encodings and/or length-prefi
xing variable-length parameters. SHA-256 <xref target="FIPS-SHS"/> is one possib
le option for F(). Note: MD5 <xref target="RFC1321"/> is considered unacceptable
for F() <xref target="RFC6151"/>.</t>
<t>In the algorithm above, the function F() provides a (stateless) unpredict
able offset for each given context (as identified by 'CONTEXT').
</t>
<t>F() is a PRF, with the same properties as those specified for F() in <xref ta
rget="cat-3-alg"/>.</t>
<t>CONTEXT is the concatenation of all the elements that define a given context. For example, if this algorithm is expected to produce identifiers that are mono tonically-increasing for each set (Source IP Address, Destination IP Address), C ONTEXT should be the concatenation of these two IP addresses.</t> <t indent="3">suitable_id() checks whether a candidate numeric identifie r has suitable uniqueness properties.</t>
<t> <t>In the algorithm above, the function F() provides a stateless, stable, an
The function F() provides a &quot;per-CONTEXT&quot; fixed offset within the d unpredictable offset for each given context (as identified by "CONTEXT"). Both
numeric identifier "space". Both the 'offset' and 'counter' variables may take the "offset" and "counter" variables may take any value within
any value within the storage type range since we are restricting the resulting identifier to
the storage type range since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described
be in the range [min_id, max_id] in a similar way as in the algorithm described in <xref target="simple-randomization" format="default"/>. This allows us
in <xref target="simple-randomization"/>. This allows us to simply increment the "counter" variable and rely on the
to simply increment the 'counter' variable and rely on the
unsigned integer to wrap around. unsigned integer to wrap around.
</t> </t>
<!--
<t>
The secret should be chosen to be as random as possible (see <xref target="RFC40
86"/> for recommendations on choosing secrets).
</t>
<t> <t>
The result of F() is no more secure than the secret key, and therefore 'secret_k The result of F() is no more secure than the secret key, and therefore, "secret_
ey' must be unknown to the attacker, and must be of a reasonable length. 'secret key" must be unknown to the attacker and must be of a reasonable length. "secret
_key' must remain stable for a given CONTEXT, since otherwise the numeric identi _key" must remain stable for a given CONTEXT, since otherwise, the numeric ident
fiers generated by this algorithm would not have the desired stability propertie ifiers generated by this algorithm would not have the desired properties (i.e.,
s (i.e., monotonically-increasing for a given CONTEXT). In most cases, 'secret_k monotonically increasing for a given CONTEXT). In most cases, "secret_key" shoul
ey' should be selected with a PRNG (see <xref target="RFC4086"/> for recommendat d be selected with a PRNG (see <xref target="RFC4086" format="default"/> for rec
ions on choosing secrets) at an appropriate time, and stored in stable or volati ommendations on choosing secrets) at an appropriate time and stored in stable or
le storage (as necessary) for future use.</t> volatile storage (as necessary) for future use.</t>
<t>It should be noted that, since this algorithm uses a global counter
<t>It should be noted that, since this algorithm uses a global counter (&quot;co ("counter") for selecting identifiers (i.e., all counters share the same increm
unter&quot;) for selecting identifiers (i.e., all counters share the same increm ent space), this algorithm results in an information leakage (as described in <x
ents space), this algorithm results in an information leakage (as described in < ref target="information-leakage" format="default"/>). For example, if this algor
xref target="information-leakage"/>). For example, if this algorithm were used f ithm was used for selecting TCP ephemeral ports and an attacker could force a cl
or selecting TCP ephemeral ports, and an attacker could force a client to period ient to periodically establish a new TCP connection to an attacker-controlled sy
ically establish a new TCP connection to an attacker-controlled system (or throu stem (or through an attacker-observable routing path), the attacker could subtra
gh an attacker-observable routing path), the attacker could subtract consecutive ct consecutive Source Port values to obtain the number of outgoing TCP connectio
source port values to obtain the number of outgoing TCP connections established ns established globally by the victim host within that time period (up to wrap-a
globally by the victim host within that time period (up to wrap-around issues a round issues and five-tuple collisions, of course). This information leakage cou
nd five-tuple collisions, of course). This information leakage could be partiall ld be partially mitigated by employing small random values for the increments (i
y mitigated by employing small random values for the increments (i.e., increment .e., increment() function), instead of having increment() return the constant "1
() function), instead of having increment() return the constant "1".</t> ".</t>
<t>We nevertheless note that an improved mitigation of this information leakage <t>We nevertheless note that an improved mitigation of this informatio
could be more successfully achieved by employing the algorithm from <xref target n leakage could be more successfully achieved by employing the algorithm from <x
="double-hash"/>, instead.</t> ref target="double-hash" format="default"/>, instead.</t>
<!--
<t>From a functional perspective, this algorithm results in numeric identifiers
with similar properties to those generated with the algorithm specified in <xref
target="per-context-counter"/> when multiple
</section> </section>
<section anchor="double-hash" numbered="true" toc="default">
<section title="Double-PRF Algorithm" anchor="double-hash"> <name>Double-PRF Algorithm</name>
<t>A trade-off between maintaining a single global "counter" variable
<t>A trade-off between maintaining a single global 'counter' variable and ma and maintaining 2**N "counter" variables (where N is the width of the result of
intaining 2**N 'counter' variables (where N is the width of the result of F()), F()) could be achieved as follows. The system would keep an array of TABLE_LENGT
could be achieved as follows. The system would keep an array of TABLE_LENGTH val H values, which would provide a separation of the increment space into multiple
ues, which would provide a separation of the increment space into multiple bucke buckets. This improvement could be incorporated into the algorithm from <xref ta
ts. This improvement could be incorporated into the algorithm from <xref target= rget="simple-hash" format="default"/> as follows:</t>
"simple-hash"/> as follows:</t> <sourcecode type="c"><![CDATA[
<t>
<figure>
<artwork>
/* Initialization code */ /* Initialization code */
for(i = 0; i &lt; TABLE_LENGTH; i++) { for(i = 0; i < TABLE_LENGTH; i++) {
table[i] = random(); table[i] = random();
} }
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
id_inc = increment() % id_range; id_inc = increment() % id_range;
offset = F(CONTEXT, secret_key1); offset = F(CONTEXT, secret_key1);
index = G(CONTEXT, secret_key2) % TABLE_LENGTH; index = G(CONTEXT, secret_key2) % TABLE_LENGTH;
retry = id_range; retry = id_range;
skipping to change at line 644 skipping to change at line 530
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry = retry - id_inc; retry = retry - id_inc;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
]]></sourcecode>
</artwork> <t>NOTE:</t>
</figure> <t indent="3">increment() has the same properties and requirements as
</t> those specified for increment() in <xref target="per-context-counter" format="de
fault"/>.</t>
<t> <t indent="3">Both F() and G() are PRFs, with the same properties as those requi
'table[]' could be initialized with random values, as indicated by the initializ red for F() in <xref target="cat-3-alg" format="default"/>. The results of F() a
ation code in the pseudo-code above.</t> nd G() are no more secure than their respective secret keys ("secret_key1" and "
secret_key2", respectively), and therefore, both secret keys must be unknown to
<!-- the attacker and must be of a reasonable length. Both secret keys must remain st
<t>Both F() and G() should be cryptographically-secure hash functions (e.g. SHA- able for the given CONTEXT, since otherwise, the transient numeric identifiers g
256 <xref target="FIPS-SHS"/>) computed over the concatenation of each of their enerated by this algorithm would not have the desired properties (i.e., monotoni
respective arguments. Both F() and G() would employ the same CONTEXT (the concat cally increasing for a given CONTEXT). In most cases, both secret keys should be
enation of all the elements that define a given context), and would use separate selected with a PRNG (see <xref target="RFC4086" format="default"/> for recomme
secret keys (secret_key1, and secret_key2, respectively). ndations on choosing secrets) at an appropriate time and stored in stable or vol
</t> atile storage (as necessary) for future use.
<t>Both F() and G() are PRFs, with the same properties as those required for F()
in <xref target="cat-3-alg"/>.</t>
<t>
The results of F() and G() are no more secure than their respective secret keys
('secret_key1' and 'secret_key2', respectively), and therefore both secret keys
must be unknown to the attacker, and must be of a reasonable length. Both secret
keys must remain stable for the given CONTEXT, since otherwise the transient nu
meric identifiers generated by this algorithm would not have the desired stabili
ty properties (i.e., monotonically-increasing for a given CONTEXT). In most case
s, both secret keys should be selected with a PRNG (see <xref target="RFC4086"/>
for recommendations on choosing secrets) at an appropriate time, and stored in
stable or volatile storage (as necessary) for future use.
</t> </t>
<t indent="3">
"table[]" could be initialized with random values, as indicated by the initializ
ation code in the pseudocode above.</t>
<!-- <t>The "table[]" array assures that successive transient numeric identifiers for
<t> a given context will be monotonically increasing. Since the increment space is
The function G() should be a cryptographic hash function. It should use the sam separated into TABLE_LENGTH different spaces, the identifier reuse frequency wil
e CONTEXT as F(), and a secret key value to compute a value between 0 and (TABLE l be (probabilistically) lower than that of the algorithm in <xref target="simpl
_LENGTH-1). e-hash" format="default"/>. That is, the generation of an identifier for one giv
en context will not necessarily result in increments in the identifier sequence
of other contexts. It is interesting to note that the size of "table[]" does not
limit the number of different identifier sequences but rather separates the <st
rong>increment space</strong> into TABLE_LENGTH different spaces. The selected t
ransient numeric identifier sequence will be obtained by adding the correspondin
g entry from "table[]" to the value in the "offset" variable, which selects the
actual identifier sequence space (as in the algorithm from <xref target="simple-
hash" format="default"/>). </t>
<t>An attacker can perform traffic analysis for any "increment
space" (i.e., context) into which the attacker has "visibility" -- namely, th
e attacker can force a system to generate identifiers for G(CONTEXT, secret_key2
), where the result of G() identifies the target "increment space". However, the
attacker's ability to perform traffic analysis is very reduced when compared to
the simple PRF-based identifiers (described in <xref target="simple-hash" forma
t="default"/>) and the predictable linear identifiers (described in <xref target
="trad_selection" format="default"/>). Additionally, an implementation can furth
er limit the attacker's ability to perform traffic analysis by further separatin
g the increment space (that is, using a larger value for TABLE_LENGTH) and/or by
randomizing the increments (i.e., increment() returning a small random number a
s opposed to the constant "1").</t>
<t>Otherwise, this algorithm does not suffer from the issues discussed
in <xref target="vulns" format="default"/>.</t>
</section>
</section>
</section>
<section anchor="vulns" numbered="true" toc="default">
<name>Common Vulnerabilities Associated with Transient Numeric Identifiers
</name>
<section anchor="activity-correlation" numbered="true" toc="default">
<name>Network Activity Correlation</name>
<t>An identifier that is predictable within a given context allows for n
etwork activity correlation within that context.</t>
<t>For example, a stable IPv6 Interface Identifier allows for network ac
tivity to be correlated within the context in which the Interface Identifier is
stable <xref target="RFC7721" format="default"/>. A stable per-network IPv6 Inte
rface Identifier (as in <xref target="RFC7217" format="default"/>) allows for ne
twork activity correlation within a network, whereas a constant IPv6 Interface I
dentifier (which remains constant across networks) allows not only network activ
ity correlation within the same network but also across networks ("host-tracking
").
</t> </t>
<t>Similarly, an implementation that generates TCP ISNs with a global co
<t>The 'table[]' array assures that successive transient numeric identifiers for unter could allow for fingerprinting and network activity correlation across net
a given context will be monotonically-increasing. Since the increments space is works, since an attacker could passively infer the identity of the victim based
separated into TABLE_LENGTH different spaces, the identifier reuse frequency wi on the TCP ISNs employed for subsequent communication instances. Similarly, an i
ll be (probabilistically) lower than that of the algorithm in <xref target="simp mplementation that generates predictable IPv6 Identification values could be sub
le-hash"/>. That is, the generation of an identifier for one given context will ject to fingerprinting attacks (see, e.g., <xref target="Bellovin2002" format="d
not necessarily result in increments in the identifier sequence of other context efault"/>).
s. It is interesting to note that the size of 'table[]' does not limit the numbe
r of different identifier sequences, but rather separates the *increment space*
into TABLE_LENGTH different spaces. The selected transient numeric identifier se
quence will be obtained by adding the corresponding entry from 'table[]' to the
value in the 'offset' variable, which selects the actual identifier sequence spa
ce (as in the algorithm from <xref target="simple-hash"/>). </t>
<t>An attacker can perform traffic analysis for any &quot;increment
space&quot; (i.e., context) into which the attacker has &quot;visibility&quot
; -- namely, the attacker can force a system to generate identifiers for G(CONTE
XT, secret_key2), where the result of G() identifies the target &quot;increment
space&quot;. However, the attacker's ability to perform traffic analysis is very
reduced when compared to the simple PRF-based identifiers (described in <xref t
arget="simple-hash"/>) and the predictable linear identifiers (described in <xre
f target="trad_selection"/>). Additionally, an implementation can further limit
the attacker's ability to perform traffic analysis by further separating the inc
rement space (that is, using a larger value for TABLE_LENGTH) and/or by randomiz
ing the increments (i.e., increment() returning a small random number as opposed
to the constant "1").</t>
<t>Otherwise, this algorithm does not suffer from the issues discussed in <xref
target="vulns"/>.</t>
</section>
</section>
</section>
<section title="Common Vulnerabilities Associated with Transient Numeric Identif
iers" anchor="vulns">
<section title="Network Activity Correlation" anchor="activity-correlation">
<t>An identifier that is predictable within a given context allows for network a
ctivity correlation within that context.</t>
<t>For example, a stable IPv6 Interface Identifier allows for network activity t
o be correlated within the context in which the Interface Identifier is stable <
xref target="RFC7721"/>. A stable-per-network IPv6 Interface Identifier (as in <
xref target="RFC7217"/>) allows for network activity correlation within a networ
k, whereas a constant IPv6 Interface Identifier (that remains constant across ne
tworks) allows not only network activity correlation within the same network, bu
t also across networks ("host tracking").
</t> </t>
</section>
<t>Similarly, an implementation that generates TCP ISNs with a global counter co <section anchor="information-leakage" numbered="true" toc="default">
uld allow for fingerprinting and network activity correlation across networks, s <name>Information Leakage</name>
ince an attacker could passively infer the identity of the victim based on the T <t>Transient numeric identifiers that result in specific patterns can pr
CP ISNs employed for subsequent communication instances. Similarly, an implement oduce an information leakage to other communicating entities. For example, it is
ation that generates predictable IPv6 Fragment Identification values could be su common to generate transient numeric identifiers with an algorithm such as:
bject to fingerprinting attacks (see e.g. <xref target="Bellovin2002"/>).
</t> </t>
</section> <sourcecode type="c"><![CDATA[
ID = offset(CONTEXT) + mono(CONTEXT);
<section title="Information Leakage" anchor="information-leakage"> ]]></sourcecode>
<t>Transient numeric identifiers that result in specific patterns can produce an <t>
information leakage to other communicating entities. For example, it is common
to generate transient numeric identifiers with an algorithm such as:
<figure align="center">
<artwork align="center"><![CDATA[
ID = offset(CONTEXT) + mono(CONTEXT);
]]></artwork>
<postamble></postamble>
</figure>
This generic expression generates identifiers by adding a monotonically-increasi
ng function (e.g. linear) to a randomized offset. offset() is constant within a
given context, whereas mono() produces a monotonically-increasing sequence for t
he given context. Identifiers generated with this expression will generally be p
redictable within CONTEXT. <!--Additionally, information associated with the inc
rements will be "leaked" within CONTEXT_2. When both CONTEXT_1 and CONTEXT_2 are
constant values, then the corresponding transient numeric identifiers become pr
edictable in all contexts.-->
<!--
<list style="hanging">
<t> This generic expression generates identifiers by adding a monotonically increasi
NOTE: If CONTEXT_1 is constant, and an attacker can sample ID values, the ng function (e.g., linear) to a randomized offset. offset() is constant within a
resulting identifiers may leak even more information. For example, if Fragment I given context, whereas mono() produces a monotonically increasing sequence for
dentification values are generated the given context. Identifiers generated with this expression will generally be
with the generic function above, CONTEXT_1 is constant, and mono() is a li predictable within CONTEXT. </t>
near function, then the corresponding identifiers will leak the number of fragme <t keepWithPrevious="true"/>
nted datagrams sent for CONTEXT_2. If both CONTEXT_1 and CONTEXT_2 are constant
, and mono() is a linear function, then Fragment Identification values will be g
enerated with a global counter (initialized to offset()), and thus each generate
d Fragment Identification value will leak the number of fragmented datagrams tra
nsmitted by the node since it has been bootstrapped.
</t>
</list> <t>The predictability of mono(), irrespective of the predictability of o
ffset(), can leak information that may be of use to attackers. For example, a no
de that selects transport-protocol ephemeral port numbers, as in:</t>
<sourcecode type="c"><![CDATA[
ephemeral_port = offset(IP_Dst_Addr) + mono()
]]></sourcecode>
<t>
that is, with a per-destination offset but a global mono() function (e.g., a glo
bal counter), will leak information about the total number of outgoing connectio
ns that have been issued by the vulnerable implementation.</t>
<t keepWithPrevious="true"/>
<t>Similarly, a node that generates IPv6 Identification values as in:
</t> </t>
<sourcecode type="c"><![CDATA[
<t>The predictability of mono(), irrespective of the predictability of offset(), ID = offset(IP_Src_Addr, IP_Dst_Addr) + mono()
can leak information that may be of use to attackers. For example, a node that ]]></sourcecode>
selects ephemeral port numbers as in: <t>
will leak out information about the total number of fragmented packets that have
<figure align="center"> been transmitted by the vulnerable implementation. The vulnerabilities describe
<artwork align="center"><![CDATA[ d in <xref target="Sanfilippo1998a" format="default"/>, <xref target="Sanfilippo
ephemeral_port = offset(Dest_IP) + mono() 1998b" format="default"/>, and <xref target="Sanfilippo1999" format="default"/>
]]></artwork> are all associated with the use of a global mono() function (i.e., with a global
<postamble></postamble> and constant "CONTEXT") -- particularly when it is a linear function (constant
</figure> increments of 1).
that is, with a per-destination offset, but a global mono() function (e.g., a gl
obal counter), will leak information about total number of outgoing connections
that have been issued by the vulnerable implementation.</t>
<t>Similarly, a node that generates Fragment Identification values as in:
<figure align="center">
<artwork align="center"><![CDATA[
Frag_ID = offset(IP_src_addr, IP_dst_addr) + mono()
]]></artwork>
<postamble></postamble>
</figure>
will leak out information about the total number of fragmented packets that have
been transmitted by the vulnerable implementation. The vulnerabilities describe
d in <xref target="Sanfilippo1998a"/>, <xref target="Sanfilippo1998b"/>, and <xr
ef target="Sanfilippo1999"/> are all associated with the use of a global mono()
function (i.e., with a global and constant "context") -- particularly when it is
a linear function (constant increments of 1).
</t> </t>
<t>Predicting transient numeric identifiers can be of help for other typ
<t>Predicting transient numeric identifiers can be of help for other types of at es of attacks. For example, predictable TCP ISNs can open the door to trivial co
tacks. For example, predictable TCP ISNs can open the door to trivial connection nnection-reset and data injection attacks (see <xref target="injection-attacks"
-reset and data injection attacks (see <xref target="injection-attacks"/>). format="default"/>).
</t> </t>
</section>
</section> <section anchor="fingerprinting" numbered="true" toc="default">
<name>Fingerprinting</name>
<section title="Fingerprinting" anchor="fingerprinting"> <t>Fingerprinting is the capability of an attacker to identify or reiden
<t>Fingerprinting is the capability of an attacker to identify or re-identify a tify a visiting user, user agent, or device via configuration settings or other
visiting user, user agent or device via configuration settings or other observab observable characteristics. Observable protocol objects and characteristics can
le characteristics. Observable protocol objects and characteristics can be emplo be employed to identify/reidentify
yed to identify/re-identify various entities. These entities can range from the underlying hardware or opera
a variety of entities, ranging from the underlying hardware or Operating ting
System (vendor, type and version), to the user itself (i.e. his/her system (OS) (vendor, type, and version) to the user. <xref target="EFF" format="
identity). <xref target="EFF"/> illustrates web browser-based fingerprinting, bu default"/> illustrates web-browser-based fingerprinting, but
t
similar techniques can be applied at other layers and protocols, whether similar techniques can be applied at other layers and protocols, whether
alternatively or in conjunction with it.</t> alternatively or in conjunction with it.</t>
<t>
<t> Transient numeric identifiers are one of the observable protocol components that
Transient numeric identifiers are one of the observable protocol components that could be leveraged for fingerprinting purposes. That is, an attacker could samp
could be leveraged for fingerprinting purposes. That is, an attacker could samp le transient numeric identifiers to infer the algorithm (and its associated para
le transient numeric identifiers to infer the algorithm (and its associated para meters, if any) for generating such identifiers, possibly revealing the underlyi
meters, if any) for generating such identifiers, possibly revealing the underlyi ng OS vendor, type, and version. This information could possibly be further leve
ng Operating System (OS) vendor, type, and version. This information could possi raged in conjunction with other fingerprinting techniques and sources.
bly be further leveraged in conjunction with other fingerprinting techniques and
sources.
</t> </t>
<t>
Evasion of protocol-stack fingerprinting can prove to be a very difficult task,
i.e., most systems make use of a wide variety of protocols, each of which have a
large number of parameters that can be set to arbitrary values or generated wit
h a variety of algorithms with multiple parameters.
<t> </t>
Evasion of protocol-stack fingerprinting can prove to be a very difficult task: <aside><t>NOTE: General protocol-based fingerprinting is discussed in
most systems make use of a wide variety of protocols, each of which have a large <xref target="RFC6973" format="default"/>,
number of parameters that can be set to arbitrary values or generated with a va
riety of algorithms with multiple parameters.
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
General protocol-based fingerprinting is discussed in <xref target="RFC6973"/
>,
along with guidelines to mitigate the associated vulnerability. along with guidelines to mitigate the associated vulnerability.
<xref target="Fyodor1998"/> and <xref target="Fyodor2006"/> are classic refer <xref target="Fyodor1998" format="default"/> and <xref target="Fyodor2006" fo
ences rmat="default"/> are classic references
on Operating System detection via TCP/IP stack fingerprinting. on OS detection via TCP/IP stack fingerprinting.
Nmap <xref target="nmap"/> is probably the most popular tool for remote OS Network Mapper <xref target="nmap" format="default"/> is probably the most po
identification via active TCP/IP stack fingerprinting. p0f <xref target="Zale pular tool for remote OS
wski2012"/>, identification via active TCP/IP stack fingerprinting. p0f <xref target="Zale
wski2012" format="default"/>,
on the other hand, is a tool for performing remote OS detection via on the other hand, is a tool for performing remote OS detection via
passive TCP/IP stack fingerprinting. Finally, <xref target="TBIT"/> is a TCP passive TCP/IP stack fingerprinting. Finally, <xref target="TBIT" format="def
fingerprinting tool that aims at characterizing the behaviour of a ault"/> is a TCP
remote TCP peer based on active probes, and which has been widely fingerprinting tool that aims at characterizing the behavior of a
remote TCP peer based on active probes, which has been widely
used in the research community. used in the research community.
</t></aside>
<t>
Algorithms that, from the perspective of an observer (e.g., the legitimate commu
nicating peer), result in specific values or patterns will allow for at least so
me level of fingerprinting. For example,
the algorithm from <xref target="cat-3-alg" format="default"/> will typically al
low fingerprinting within the context where the resulting identifiers are stable
. Similarly, the algorithms from <xref target="cat-4-alg" format="default"/> wil
l result in monotonically increasing sequences within a given context, thus allo
wing for at least some level of fingerprinting (when the other communicating ent
ity can correlate different sampled identifiers as belonging to the same monoton
ically increasing sequence).
</t> </t>
</list> <t>
</t> Thus, where possible, algorithms from <xref target="cat-1-alg" format="default"/
> should be preferred over algorithms that result in specific values or patterns
<t> .
Algorithms that, from the perspective of an observer (e.g., the legitimate commu
nicating peer), result in specific values or patterns, will allow for at least s
ome level of fingerprinting. For example,
the algorithm from <xref target="cat-3-alg"/> will typically allow fingerprintin
g within the context where the resulting identifiers are stable. Similarly, the
algorithms from <xref target="cat-4-alg"/> will result in a monotonically-increa
sing sequences within a given context, thus allowing for at least some level of
fingerprinting (when the other communicating entity can correlate different samp
led identifiers as belonging to the same monotonically-increasing sequence).
</t>
<t>
Thus, where possible, algorithms from <xref target="cat-1-alg"/> should be prefe
rred over algorithms that result in specific values or patterns.
</t>
</section>
<section title="Exploitation of the Semantics of Transient Numeric Identifiers"
anchor="id-semantics">
<t>Identifiers that are not semantically opaque tend to be more predictable than
semantically-opaque identifiers. For example, a MAC address contains an OUI (Or
ganizationally-Unique Identifier) which may identify the vendor that manufacture
d the corresponding network interface card. This can be leveraged by an attacker
trying to "guess" MAC addresses, who has some knowledge about the possible Netw
ork Interface Card (NIC) vendor.</t>
<t><xref target="RFC7707"/> discusses a number of techniques to reduce the searc
h space when performing IPv6 address-scanning attacks by leveraging the semantic
s of the IIDs produced by traditional SLAAC algorithms (eventually replaced by <
xref target="RFC7217"/>) that embed MAC addresses in the IID of IPv6 addresses.
</t> </t>
</section> </section>
<section anchor="id-semantics" numbered="true" toc="default">
<section title="Exploitation of Collisions of Transient Numeric Identifiers" anc <name>Exploitation of the Semantics of Transient Numeric Identifiers</na
hor="id-collisions"> me>
<t>In many cases, the collision of transient network identifiers can have a hard <t>Identifiers that are not semantically opaque tend to be more predicta
failure severity (or result in a hard failure severity if an attacker can cause ble than semantically opaque identifiers. For example, a Media Access Control (M
multiple collisions deterministically, one after another). For example, predict AC) address contains an Organizationally Unique Identifier (OUI), which may ide
able Fragment Identification values open the door to Denial of Service (DoS) att ntify the vendor that manufactured the corresponding network interface card. Thi
acks (see e.g. <xref target="RFC5722"/>.). s can be leveraged by an attacker trying to "guess" MAC addresses, who has some
knowledge about the possible Network Interface Card (NIC) vendor.</t>
<t><xref target="RFC7707" format="default"/> discusses a number of techn
iques to reduce the search space when performing IPv6 address-scanning attacks b
y leveraging the semantics of IPv6 IIDs.
</t> </t>
</section> </section>
<section anchor="id-collisions" numbered="true" toc="default">
<section title="Exploitation of Predictable Transient Numeric Identifiers for In <name>Exploitation of Collisions of Transient Numeric Identifiers</name>
jection Attacks" anchor="injection-attacks"> <t>In many cases, the collision of transient network identifiers can hav
<t>Some protocols rely on "sequence numbers" for the validation of incoming pack e a hard failure severity (or result in a hard failure severity if an attacker c
ets. For example, TCP employs sequence numbers for reassembling TCP segments, wh an cause multiple collisions deterministically, one after another). For example,
ile IPv4 and IPv6 employ Fragment Identification values for reassembling IPv4 an predictable IP Identification values open the door to Denial of Service (DoS) a
d IPv6 fragments (respectively). Lacking built-in cryptographic mechanisms for v ttacks (see, e.g., <xref target="RFC5722" format="default"/>.).
alidating packets, these protocols are therefore vulnerable to on-path data (see
e.g. <xref target="Joncheray1995"/>) and/or control-information (see e.g. <xref
target="RFC4953"/> and <xref target="RFC5927"/>) injection attacks. The extent
to which these protocols may resist off-path (i.e. "blind") injection attacks de
pends on whether the associated "sequence numbers" are predictable, and effort r
equired to successfully predict a valid "sequence number" (see e.g. <xref target
="RFC4953"/> and <xref target="RFC5927"/>).
</t> </t>
</section>
<t>We note that the use of unpredictable "sequence numbers" is a completely-inef <section anchor="injection-attacks" numbered="true" toc="default">
fective mitigation for on-path injection attacks, and also a mostly-ineffective <name>Exploitation of Predictable Transient Numeric Identifiers for Inje
mitigation for off-path (i.e. "blind") injection attacks. However, many legacy p ction Attacks</name>
rotocols (such as TCP) do not natively incorporate cryptographic mitigations, bu <t>Some protocols rely on "sequence numbers" for the validation of incom
t rather only as optional features (see e.g. <xref target="RFC5925"/>), if at al ing packets. For example, TCP employs sequence numbers for reassembling TCP segm
l available. Additionally, ad-hoc use of cryptographic mitigations might not be ents, while IPv4 and IPv6 employ Identification values for reassembling IPv4 and
sufficient to relieve a protocol implementation of generating appropriate transi IPv6 fragments (respectively). Lacking built-in cryptographic mechanisms for va
ent numeric identifiers. For example, use of the Transport Layer Security (TLS) lidating packets, these protocols are therefore vulnerable to on-path data (see,
protocol <xref target="RFC8446"/> with TCP will protect the application protocol e.g., <xref target="Joncheray1995" format="default"/>) and/or control-informat
, but will not help to mitigate e.g. TCP-based connection-reset attacks (see e.g ion (see, e.g., <xref target="RFC4953" format="default"/> and <xref target="RFC5
. <xref target="RFC4953"/>). Similarly, use of SEcure Neighbor Discovery (SEND) 927" format="default"/>) injection attacks. The extent to which these protocols
<xref target="RFC3971"/> will still imply reliance on the successful reassembly may resist off-path (i.e., "blind") injection attacks depends on whether the ass
of IPv6 fragments in those cases where SEND packets do not fit into the link Max ociated "sequence numbers" are predictable and the effort required to successful
imum Transmission Unit (MTU) (see <xref target="RFC6980"/>).</t> ly predict a valid "sequence number" (see, e.g., <xref target="RFC4953" format="
default"/> and <xref target="RFC5927" format="default"/>).
</section>
<section title="Cryptanalysis" anchor="crypto-analisis">
<t>A number of algorithms discussed in this document (such as those described in
<xref target="simple-hash"/> and <xref target="double-hash"/>) rely on PRFs. Im
plementations that employ weak PRFs or keys of inappropriate size can be subject
to cryptanalysis, where an attacker can obtain the secret key employed for the
PRF, predict numeric identifiers, etc. </t>
<t>Furthermore, an implementation that overloads the semantics of the secret key
can result in more trivial cryptanalysis, possibly resulting in the leakage of
the value employed for the secret key.
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
<xref target="IPID-DEV"/> describes two vulnerable transient numeric ID generato
rs that employ cryptographically-weak hash functions. Additionally, one of such
implementations employs 32-bits of a kernel address as the secret key for a hash
function, and therefore successful cryptanalysis leaks the aforementioned kerne
l address, allowing for Kernel Address Space Layout Randomization (KASLR) <xref
target="KASLR"/> bypass.
</t> </t>
</list> <t>We note that the use of unpredictable "sequence numbers" is a completely inef
fective mitigation for on-path injection attacks and also a mostly ineffective m
itigation for off-path (i.e., "blind") injection attacks.
However, many legacy protocols (such as TCP) do not incorporate cryptographic mi
tigations as part of the core protocol but rather as optional features (see, e.g
., <xref target="RFC5925" format="default"/>), if available at all.
Additionally, ad hoc use of cryptographic mitigations might not be sufficient to
relieve a protocol implementation of generating appropriate transient numeric i
dentifiers. For example, use of the Transport Layer Security (TLS) protocol <xre
f target="RFC8446" format="default"/> with TCP will protect the application prot
ocol but will not help to mitigate, e.g., TCP-based connection-reset attacks (se
e, e.g., <xref target="RFC4953" format="default"/>). Similarly, use of SEcure Ne
ighbor Discovery (SEND) <xref target="RFC3971" format="default"/> will still imp
ly reliance on the successful reassembly of IPv6 fragments in those cases where
SEND packets do not fit into the link Maximum Transmission Unit (MTU) (see <xref
target="RFC6980" format="default"/>).</t>
</section>
<section anchor="crypto-analisis" numbered="true" toc="default">
<name>Cryptanalysis</name>
<t>A number of algorithms discussed in this document (such as those desc
ribed in Sections <xref target="simple-hash" format="counter"/> and <xref target
="double-hash" format="counter"/>) rely on PRFs. Implementations that employ wea
k PRFs or keys of inappropriate size can be subject to cryptanalysis, where an a
ttacker can obtain the secret key employed for the PRF, predict numeric identifi
ers, etc. </t>
<t>Furthermore, an implementation that overloads the semantics of the se
cret key can result in more trivial cryptanalysis, possibly resulting in the lea
kage of the value employed for the secret key.
</t> </t>
</section> <aside><t>NOTE: <xref target="IPID-DEV" format="default"/> describes t
</section> wo vulnerable transient numeric identifier generators that employ cryptographica
lly weak hash functions. Additionally, one of such implementations employs 32 bi
<section title="Vulnerability Assessment of Transient Numeric Identifiers" ancho ts of a kernel address as the secret key for a hash function, and therefore, suc
r="vuln-cats"> cessful cryptanalysis leaks the aforementioned kernel address, allowing for Kern
<t> el Address Space Layout Randomization (KASLR) <xref target="KASLR" format="defau
The following subsections analyze possible vulnerabilities associated with the a lt"/> bypass.</t></aside>
lgorithms described in <xref target="common-algorithms"/>. </section>
</section>
<section anchor="vuln-cats" numbered="true" toc="default">
<name>Vulnerability Assessment of Transient Numeric Identifiers</name>
<t>
The following subsections analyze possible vulnerabilities associated with the a
lgorithms described in <xref target="common-algorithms" format="default"/>.
</t> </t>
<section anchor="cat-1-vuln" numbered="true" toc="default">
<section title="Category #1: Uniqueness (soft failure)" anchor="cat-1-vuln"> <name>Category #1: Uniqueness (Soft Failure)</name>
<t>Possible vulnerabilities associated with the algorithms from <xref target="ca <t>Possible vulnerabilities associated with the algorithms from <xref ta
t-1-alg"/> include: rget="cat-1-alg" format="default"/> include the following:
<list style="symbols">
<t>Use of flawed PRNGs (please see e.g. <xref target="Zalewski2001"/>, <xref tar
get="Zalewski2002"/>, <xref target="Klein2007"/> and <xref target="CVEs"/>).</t>
<t>Inadvertently affecting the distribution of an otherwise suitable PRNG (pleas
e see e.g. <xref target="Romailler2020"/>).</t>
</list>
</t> </t>
<ul spacing="normal">
<li>use of flawed PRNGs (please see, e.g., <xref target="Zalewski2001"
format="default"/>, <xref target="Zalewski2002" format="default"/>, <xref targe
t="Klein2007" format="default"/>, and <xref target="CVEs" format="default"/>)</l
i>
<li>inadvertently affecting the distribution of an otherwise suitable
PRNG (please see, e.g., <xref target="Romailler2020" format="default"/>)</li>
</ul>
<t>Where available, CSPRNGs should be preferred over regular PRNGs, such
as, e.g., POSIX random(3) implementations. In scenarios where a CSPRNG is not r
eadily available, a security and privacy assessment of employing a regular PRNG
should be performed, supporting the implementation decision.
<t>Where available, CSPRNGs should be preferred over regular PRNGs such as e.g.
POSIX random(3) implementations. In scenarios where a CSPRNG is not readily avai
lable, a security and privacy assessment of employing a regular PRNG should be p
erformed, supporting the implementation decision.
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
Please see <xref target="RFC4086"/> regarding randomness requirements for securi
ty. <xref target="Aumasson2018"/>, <xref target="Press1992"/>, and <xref target=
"Knuth1983"/>, discuss theoretical and practical aspects of random numbers gener
ation, and provide guidance on how to evaluate PRNGs.</t>
</list>
</t> </t>
<aside><t>NOTE: Please see <xref target="RFC4086" format="default"/> r
<t>When employing a PRNG, many implementations "adapt" the length of its output egarding randomness requirements for security. <xref target="Aumasson2018" forma
with a modulo operator (e.g., C language's "%"), possibly changing the distribut t="default"/>, <xref target="Press1992" format="default"/>, and <xref target="Kn
ion of the output of the PRNG.</t> uth1983" format="default"/> discuss theoretical and practical aspects of random
number generation and provide guidance on how to evaluate PRNGs.</t></aside>
<t> <t>When employing a PRNG, many implementations "adapt" the length of its
output with a modulo operator (e.g., C language's "%"), possibly changing the d
istribution of the output of the PRNG.</t>
<t>
For example, consider an implementation that employs the following code: For example, consider an implementation that employs the following code:
<figure align="center">
<artwork align="center"><![CDATA[
id = random() % 50000;
]]></artwork>
<postamble></postamble>
</figure>
This example implementation means to obtain a transient numeric identifier in th
e range 0-49999. If random() produces e.g. a pseudorandom number of 16 bits (wit
h uniform distribution), the selected transient numeric identifier will have a n
on-uniform distribution with the numbers in the range 0-15535 having double-freq
uency than the numbers in the range 15536-49999.
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
For example, in our sample code both an output of 10 and output of 50010 from th
e random() function will result in an 'id' value of 10.
</t> </t>
</list> <sourcecode type="c"><![CDATA[
id = random() % 50000;
This effect is reduced if the PRNG produces an output that is much longer than t ]]></sourcecode>
he length implied by the modulo operation. We note that to preserve a uniform di <t>
stribution, the rejection sampling technique <xref target="Romailler2020"/> can This example implementation means to obtain a transient numeric identifier in th
be used. e range 0-49999. If random() produces, e.g., a pseudorandom number of 16 bits (w
ith uniform distribution), the selected transient numeric identifier will have a
nonuniform distribution with the numbers in the range 0-15535 having double fre
quency than the numbers in the range 15536-49999.
</t> </t>
<t keepWithPrevious="true"/>
<aside><t>NOTE: For example, in our sample code, both an output of 10
and output of 50010 from the random() function will result in an "id" value of 1
0.
</t></aside>
<t> <t>
This effect is reduced if the PRNG produces an output that is much longer than t
he length implied by the modulo operation. We note that to preserve a uniform di
stribution, the rejection sampling technique <xref target="Romailler2020" format
="default"/> can be used.
</t>
<t>
Use of algorithms other than PRNGs for generating identifiers of this category i s discouraged. Use of algorithms other than PRNGs for generating identifiers of this category i s discouraged.
</t> </t>
</section>
</section> <section anchor="cat-2-vuln" numbered="true" toc="default">
<name>Category #2: Uniqueness (Hard Failure)</name>
<section title="Category #2: Uniqueness (hard failure)" anchor="cat-2-vuln"> <t>As noted in <xref target="cat-2-alg" format="default"/>, this categor
<t>As noted in <xref target="cat-2-alg"/>, this category can employ the same alg y can employ the same algorithms as Category #4, since a monotonically increasin
orithms as Category #4, since a monotonically-increasing sequence tends to minim g sequence tends to minimize the transient numeric identifier reuse frequency. T
ize the transient numeric identifier reuse frequency. Therefore, the vulnerabili herefore, the vulnerability analysis in <xref target="cat-4-vuln" format="defaul
ty analysis in <xref target="cat-4-vuln"/> also applies to this category. t"/> also applies to this category.
</t> </t>
<t>Additionally, as noted in <xref target="cat-2-alg" format="default"/>
<t>Additionally, as noted in <xref target="cat-2-alg"/>, some transient numeric , some transient numeric identifiers of this category might be able to use the a
identifiers of this category might be able to use the algorithms from <xref tar lgorithms from <xref target="cat-1-alg" format="default"/>, in which case the s
get="cat-1-alg"/>, in which case the same considerations as in <xref target="cat ame considerations as in <xref target="cat-1-vuln" format="default"/> would appl
-1-vuln"/> would apply. y.
</t> </t>
</section> </section>
<section anchor="cat-3-vuln" numbered="true" toc="default">
<name>Category #3: Uniqueness, Stable within Context (Soft Failure)</nam
e>
<section title="Category #3: Uniqueness, stable within context (soft failure)" a <t>Possible vulnerabilities associated with the algorithms from <xref target="ca
nchor="cat-3-vuln"> t-3-alg" format="default"/> are the following:
<!--
<t>There are three main vulnerabilities that may be associated with identifiers
of this category:
<list style="numbers">
<t>Use algorithms or sources that result in predictable identifiers</t>
<t>Use cryptographically-weak hash functions, or inappropriate secret key sizes
that allow for cryptanalysis</t>
<t>Employing the same identifier across contexts in which stability is not requi
red (overloading the numeric identifier)</t>
</list>
</t>
<t>Possible vulnerabilities associated with the algorithms from <xref target="ca
t-3-alg"/> are:
<list style="numbers">
<t>Use of weak PRFs, or inappropriate secret keys (whether inappropriate selecti
on or inappropriate size) could allow for cryptanalysis, which could eventually
be exploited by an attacker to predict future transient numeric identifiers.</t>
<t>Since the algorithm generates a unique and stable identifier within a specifi
ed context, it may allow for network activity correlation and fingerprinting wit
hin the specified context.</t>
</list>
</t> </t>
<ul spacing="normal"><li>Use of weak PRFs or inappropriate secret keys (
</section> whether inappropriate selection or inappropriate size) could allow for cryptanal
ysis, which could eventually be exploited by an attacker to predict future trans
<section title="Category #4: Uniqueness, monotonically increasing within context ient numeric identifiers.</li>
(hard failure)" anchor="cat-4-vuln"> <li>Since the algorithm generates a unique and stable identifier withi
<t>The algorithm described in <xref target="per-context-counter"/> for generatin n a specified context, it may allow for network activity correlation and fingerp
g identifiers of Category #4 will result in an identifiable pattern (i.e. a mono rinting within the specified context.</li>
tonically-increasing sequence) for the transient numeric identifiers generated f </ul>
or each CONTEXT, and thus will allow for fingerprinting and network activity cor </section>
relation within each CONTEXT. <section anchor="cat-4-vuln" numbered="true" toc="default">
<name>Category #4: Uniqueness, Monotonically Increasing within Context (
Hard Failure)</name>
<t>The algorithm described in <xref target="per-context-counter" format=
"default"/> for generating identifiers of Category #4 will result in an identifi
able pattern (i.e., a monotonically increasing sequence) for the transient numer
ic identifiers generated for each CONTEXT, and thus will allow for fingerprintin
g and network activity correlation within each CONTEXT.
</t> </t>
<t>On the other hand, a simple way to generalize and analyze the algorit
<t>On the other hand, a simple way to generalize and analyze the algorithms desc hms described in Sections <xref target="simple-hash" format="counter"/> and <xre
ribed in <xref target="simple-hash"/> and <xref target="double-hash"/> for gener f target="double-hash" format="counter"/> for generating identifiers of Category
ating identifiers of Category #4, is as follows: #4 is as follows:
<figure> </t>
<artwork> <sourcecode type="c"><![CDATA[
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
retry = id_range; retry = id_range;
id_inc = increment() % id_range; id_inc = increment() % id_range;
do { do {
update_mono(CONTEXT, id_inc); update_mono(CONTEXT, id_inc);
next_id = min_id + (offset(CONTEXT) + \ next_id = min_id + (offset(CONTEXT) + \
mono(CONTEXT)) % id_range; mono(CONTEXT)) % id_range;
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry = retry - id_inc; retry = retry - id_inc;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
]]></sourcecode>
</artwork> <t>NOTE:</t>
</figure> <t indent="3">increment() returns a small integer that is employed to
</t> generate a monotonically increasing function. Most implementations employ a cons
tant value for "increment()" (usually 1). The value returned by increment() must
<t> be much smaller than the value computed for "id_range".
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
increment() returns a small integer that is employed to generate a monotonically
-increasing function. Most implementations employ a constant value for "incremen
t()" (usually 1). The value returned by increment() must be much smaller than th
e value computed for "id_range".
</t>
<t>
update_mono(CONTEXT, id_inc) increments the counter corresponding to CONTEXT by
"id_inc".
</t>
<t>
mono(CONTEXT) reads the counter corresponding to CONTEXT.
</t>
</list>
</t>
<t>Essentially, an identifier (next_id) is generated by adding a monotonically-i
ncreasing function (mono()) to an offset value, unknown to the attacker and stab
le for given context (CONTEXT).</t>
<t>The following aspects of the algorithm should be considered:
<list style="symbols">
<t>For the most part, it is the offset() function that results in identifiers th
at are unpredictable by an off-patch attacker. While the resulting sequence is k
nown to be monotonically-increasing, the use of a randomized offset value makes
the resulting values unknown to the attacker.</t>
<t>The most straightforward "stateless" implementation of offset() is with a PRF
that takes the values that identify the context and a "secret_key" (not shown i
n the figure above) as arguments.
</t>
<t>
One possible implementation of mono() would be to have mono() internally employ
a single counter (as in the algorithm from <xref target="simple-hash"/>), or map
the increments for different contexts into a number of counters/buckets, such t
hat the number of counters that need to be maintained in memory is reduced (as i
n the algorithm from algorithm in <xref target="double-hash"/>).
</t>
<!--
<t>
One possible implementation approach for mono() is to maintain per-context count
ers, initialized to random values (as the algorithm from <xref target="per-conte
xt-counter"/>). When a new identifier is to be selected, the corresponding count
er is looked-up (based on the context) and incremented, to obtain a new transien
t numeric identifier. For example, the algorithm in <xref target="per-context-co
unter"/> could be such an implementation of mono(). Another possible implementa
tion of mono() would be to have mono() internally employ a single counter (as in
the algorithm from <xref target="simple-hash"/>), or map the increments for dif
ferent contexts into a number of counters/buckets, such that the number of count
ers that need to be maintained in memory is reduced (as in the algorithm from al
gorithm in <xref target="double-hash"/>).
</t>
<t>In all cases, a monotonically increasing function is implemented by increment
ing the previous value of a counter by increment() units. In the most trivial ca
se, increment() could return the constant "1". But increment() could also be imp
lemented to return small random integers such that the increments are unpredicta
ble (see Appendix A of <xref target="RFC7739"/>). This represents a trade-off be
tween the unpredictability of the resulting transient numeric IDs and the transi
ent numeric ID reuse frequency.
</t>
</list>
</t> </t>
<t indent="3">update_mono(CONTEXT, id_inc) increments the counter corresponding
<t>Considering the generic algorithm illustrated above, we can identify the foll to CONTEXT by "id_inc".
owing possible vulnerabilities:
<list style="symbols">
<t>Since the algorithms for this category are similar to those of <xref target="
cat-3-vuln"/>, with the addition of a monotonically-increasing function, all the
issues discussed in <xref target="cat-3-vuln"/> ("Category #3: Uniqueness, stab
le within context (soft failure)") also apply to this case.
</t> </t>
<t indent="3">mono(CONTEXT) reads the counter corresponding to CONTEXT.
<t>mono() can be correlated to the number of identifiers generated for a given c
ontext (CONTEXT). Thus, if mono() spans more than the necessary context, the "in
crements" could be leaked to other parties, thus disclosing information about th
e number of identifiers that have been generated by the algorithm for all contex
ts. This is information disclosure becomes more evident when an implementation e
mploys a constant increment of 1. For example, an implementation where mono() is
actually a single global counter, will unnecessarily leak information the numbe
r of identifiers that have been generated by the algorithm (globally, for all co
ntexts). <xref target="Fyodor2003"/> is one example of how such information leak
ages can be exploited. We note that limiting the span of the increments space wi
ll require a larger number of counters to be stored in memory (i.e., a larger va
lue for the TABLE_LENGTH parameter of the algorithm in <xref target="double-hash
"/>).
</t> </t>
<t>Essentially, an identifier (next_id) is generated by adding a monoton
ically increasing function (mono()) to an offset value, which is unknown to the
attacker and stable for given context (CONTEXT).</t>
<t>The following aspects of the algorithm should be considered:
<t>Transient numeric identifiers generated with the algorithms described in <xre f target="simple-hash"/> and <xref target="double-hash"/> will normally allow fo r fingerprinting within CONTEXT since, for such context, the resulting identifie rs will have an identifiable pattern (i.e. a monotonically-increasing sequence).
</t> </t>
<ul spacing="normal">
<li>For the most part, it is the offset() function that results in ide
ntifiers that are unpredictable by an off-patch attacker. While the resulting se
quence is known to be monotonically increasing, the use of a randomized offset v
alue makes the resulting values unknown to the attacker.</li>
<li>The most straightforward "stateless" implementation of offset() is
with a PRF that takes the values that identify the context and a secret key (no
t shown in the figure above) as arguments.
</li>
<li>
One possible implementation of mono() would be to have mono() internally employ
a single counter (as in the algorithm from <xref target="simple-hash" format="de
fault"/>) or map the increments for different contexts into a number of counters
/buckets, such that the number of counters that need to be maintained in memory
is reduced (as in the "Double-PRF Algorithm" from <xref target="double-hash" for
mat="default"/>).
</li>
</list> <li>In all cases, a monotonically increasing function is implemented by incremen
ting the previous value of a counter by increment() units. In the most trivial c
ase, increment() could return the constant "1". But increment() could also be im
plemented to return small random integers such that the increments are unpredict
able (see <xref target="random-increments"/> of this document). This represents
a trade-off between the unpredictability of the resulting transient numeric iden
tifiers and the transient numeric identifier reuse frequency.
</li>
</ul>
<t>Considering the generic algorithm illustrated above, we can identify
the following possible vulnerabilities:
</t> </t>
</section> <ul spacing="normal">
</section> <li>Since the algorithms for this category are similar to those of <xr
ef target="cat-3-vuln" format="default"/>, with the addition of a monotonically
<section title="IANA Considerations" anchor="iana-considerations"> increasing function, all the issues discussed in <xref target="cat-3-vuln" forma
<t>This document has no IANA actions.</t> t="default"/> ("Category #3: Uniqueness, Stable within Context (Soft Failure)")
</section> also apply to this case.
</li>
<section title="Security Considerations"> <li>mono() can be correlated to the number of identifiers generated for a given
context (CONTEXT). Thus, if mono() spans more than the necessary context, the "i
ncrements" could be leaked to other parties, thus disclosing information about t
he number of identifiers that have been generated by the algorithm for all conte
xts. This information disclosure becomes more evident when an implementation emp
loys a constant increment of 1.
<t>The entire document is about the security and privacy implications of For example, an implementation where mono() is actually a single global counter
transient numeric identifiers. <xref target="I-D.gont-numeric-ids-sec-considerat will unnecessarily leak information about the number of identifiers that have be
ions"/> recommends that protocol specifications specify the interoperability req en generated by the algorithm (globally, for all contexts). <xref target="Fyodor
uirements of their transient numeric identifiers, perform a vulnerability assess 2003" format="default"/> describes one example of how such information leakages
ment of their transient numeric identifiers, and suggest an algorithm for genera can be exploited. We note that limiting the span of the increment space will req
ting each of their transient numeric identifiers. This document analyzes possibl uire a larger number of counters to be stored in memory (i.e., a larger value fo
e algorithms (and their implications) that could be employed to comply with the r the TABLE_LENGTH parameter of the algorithm in <xref target="double-hash" form
interoperability properties of most common categories of transient numeric ident at="default"/>).
ifiers, while minimizing the associated negative security and privacy implicatio </li>
ns.</t> <li>Transient numeric identifiers generated with the algorithms descri
bed in Sections <xref target="simple-hash" format="counter"/> and <xref target="
double-hash" format="counter"/> will normally allow for fingerprinting within CO
NTEXT since, for such context, the resulting identifiers will have an identifiab
le pattern (i.e., a monotonically increasing sequence).
</li>
</ul>
</section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section title="Acknowledgements"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>The authors would like to thank (in alphabetical order) Bernard Aboba, Jean-P </section>
hilippe Aumasson, Steven Bellovin, Luis Leon Cardenas Graide, Spencer Dawkins, T <section numbered="true" toc="default">
heo de Raadt, Guillermo Gont, Joseph Lorenzo Hall, Gre Norcie, Colin Perkins, Vi <name>Security Considerations</name>
ncent Roca, Shivan Sahib, Rich Salz, Martin Thomson, and Michael Tuexen, for pro <t>This entire document is about the security and privacy implications of
viding valuable comments on earlier versions of this document.</t> transient numeric identifiers. <xref target="RFC9416" format="default"/> recomme
nds that protocol specifications specify the interoperability requirements of th
<t>The authors would like to thank Shivan Sahib and Christopher Wood, for their eir transient numeric identifiers, perform a vulnerability assessment of their t
guidance during the publication process of this document.</t> ransient numeric identifiers, and recommend an algorithm for generating each of
their transient numeric identifiers. This document analyzes possible algorithms
<t>The authors would like to thank Jean-Philippe Aumasson and Mathew D. Green (J (and their implications) that could be employed to comply with the interoperabil
ohn Hopkins University) for kindly answering a number of questions.</t> ity requirements of the most common categories of transient numeric identifiers
while minimizing the associated negative security and privacy implications.</t>
<t>The authors would like to thank Diego Armando Maradona for his magic and ins
piration.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title='Normative References'>
<!--
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.8174" ?>
<!-- TCP sequence numbers -->
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.6528" ?> <!-- TCP SEQ randomization -->
<!-- Port Randomization -->
<?rfc include="reference.RFC.6056" ?>
<!-- TCP-AO -->
<?rfc include="reference.RFC.5925" ?>
<!-- IPv4 -->
<?rfc include="reference.RFC.0791" ?>
<!-- IPv6 -->
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.8200" ?>
<?rfc include="reference.RFC.4086" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.8981" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.5722" ?>
<?rfc include="reference.RFC.7217" ?>
<?rfc include="reference.RFC.8064" ?>
<!-- IPv6 Flow Label --> <references>
<?rfc include="reference.RFC.6437" ?> <name>References</name>
<references>
<!-- TCP timestamps --> <name>Normative References</name>
<?rfc include="reference.RFC.6191" ?>
<?rfc include="reference.RFC.7323" ?>
<!-- MD5 -->
<?rfc include="reference.RFC.1321" ?>
<?rfc include="reference.RFC.6151" ?>
<!-- DNS -->
<?rfc include="reference.RFC.1035" ?>
</references>
<references title='Informative References'>
<!-- Timing attacks -->
<!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.07
<reference anchor="Mayer2014" target="https://www.blackhat.com/docs/us-14 93.xml"/>
/materials/us-14-Mayer-Time-Trial-Racing-Towards-Practical-Timing-Attacks-WP.pdf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
"> 528.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
<title>Time Trial: Racing Towards Practical Remote Timing 56.xml"/>
Attacks</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<author initials="D." surname="Mayer" fullname="Daniel Ma 25.xml"/>
yer"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.07
<organization>Matasano</organization> 91.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author initials="J." surname="Sandin" fullname="Joel San 460.xml"/>
din"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<organization>Matasano</organization> 200.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date year="2014"/> 086.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="BlackHat USA 2014 Conference," value="August 6- 291.xml"/>
7"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 981.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
862.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
722.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
217.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
064.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
37.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.61
91.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
323.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.13
21.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
151.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.10
35.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
05.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
93.xml"/>
<!-- </references>
<reference anchor="Crosby2009" target="https://www.cs.rice.edu/~dwallach/ <references>
pub/crosby-timing2009.pdf"> <name>Informative References</name>
<front>
<title>Opportunities and Limits of Remote Timing Attacks<
/title>
<author initials="S. A." surname="Crosby" fullname="Scott
A. Crosby">
<organization>Rice University</organization>
</author>
<author initials="D. S." surname="Wallach" fullname="Dan
S. Wallach">
<organization>Rice University</organization>
</author>
<author initials="R. H." surname="Riedi" fullname="Rudolf
H. Riedi">
<organization>Rice University</organization>
</author>
<date year="2009"/>
</front>
<seriesInfo name="ACM Trans. Inf. Syst. Secur. 12, 3, " value="Ar
ticle 17 "/>
</reference>
<reference anchor="KASLR" target="https://pax.grsecurity.net/docs/aslr.tx t"> <reference anchor="KASLR" target="https://pax.grsecurity.net/docs/aslr.tx t">
<front> <front>
<title>Address Space Layout Randomization</title> <title>Address Space Layout Randomization</title>
<author initials="" surname="PaX Team" fullname="The Pax <author>
Team"> <organization>PaX Team</organization>
<organization></organization> </author>
</author> </front>
<date/>
</front>
<!--
<seriesInfo name="" value="Federal Information Processing Standar
ds Publication 180-4"/>
</reference>
<reference anchor="IANA-PROT" target="https://www.iana.org/protocols">
<front>
<title>Protocol Registries</title>
<author initials="" surname="IANA" fullname="IANA">
<organization></organization>
</author>
<date/>
</front>
<!--
<seriesInfo name="" value="Federal Information Processing Standar
ds Publication 180-4"/>
</reference>
<!-- Fingerprinting -->
<?rfc include="reference.RFC.6973" ?>
<reference anchor="Fyodor1998" target="http://www.phrack.org/archives/iss
ues/54/9.txt">
<front>
<title>Remote OS Detection via TCP/IP Stack Fingerprintin
g</title>
<author initials="" surname="Fyodor" fullname="Fyodor">
<organization></organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="" value="Phrack Magazine, Volume 9, Issue 54"/>
</reference> </reference>
<reference anchor="Fyodor2006" target="https://nmap.org/book/osdetect.htm <reference anchor="IANA-PROT" target="https://www.iana.org/protocols">
l"> <front>
<front> <title>Protocol Registries</title>
<title>Chapter 8. Remote OS Detection</title> <author>
<author initials="G." surname="Lyon" fullname="Gordon Lyo <organization>IANA</organization>
n"> </author>
<organization></organization> </front>
</author>
<date year="2006"/>
</front>
</reference> </reference>
<reference anchor="nmap" target="https://www.insecure.org/nmap"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
<front> 73.xml"/>
<title>Nmap: Free Security Scanner For Network Exploratio
n and Audit</title>
<author>
<organization>nmap</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="EFF" target="https://coveryourtracks.eff.org/"> <reference anchor="Fyodor1998" target="http://www.phrack.org/archives/is
<front> sues/54/9.txt">
<title>Cover your tracks: See how trackers view your brow <front>
ser</title> <title>Remote OS detection via TCP/IP Stack FingerPrinting</title>
<author initials="" surname="EFF" fullname="EFF"> <author>
<organization></organization> <organization>Fyodor</organization>
</author> </author>
<date year="2020"/> <date year="1998" month="December"/>
</front> </front>
<refcontent>Phrack Magazine, Volume 8, Issue 54</refcontent>
</reference>
</reference> <reference anchor="Fyodor2006" target="https://nmap.org/book/osdetect.ht
ml">
<front>
<title>Chapter 8. Remote OS Detection</title>
<author initials="G." surname="Lyon" fullname="Gordon Lyon">
<organization/>
</author>
<date year="2009" month="January"/>
</front>
</reference>
<reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/c <reference anchor="nmap" target="https://nmap.org/">
hristoph-schuba/schuba-DNS-msthesis.pdf"> <front>
<front> <title>Nmap: Free Security Scanner For Network Exploration and Audit
<title>ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PR </title>
OTOCOL</title> <author>
<author initials="C." surname="Schuba" fullname="Christop <organization>nmap</organization>
h Schuba"> </author>
<organization></organization> <date year="2020"/>
</author> </front>
<date year="1993"/> </reference>
</front>
</reference>
<reference anchor="TBIT" target="https://www.icir.org/tbit/"> <reference anchor="EFF" target="https://coveryourtracks.eff.org/">
<front> <front>
<title>TBIT, the TCP Behavior Inference Tool</title> <title>Cover your tracks: See how trackers view your browser</title>
<author initials="" surname="TBIT" fullname="TBIT"> <author>
<organization></organization> <organization>EFF</organization>
</author> </author>
<date year="2001"/> </front>
</front> </reference>
</reference> <reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/
papers/christoph-schuba/schuba-DNS-msthesis.pdf">
<front>
<title>Addressing Weakness in the Domain Name System Protocol</title
>
<author initials="C." surname="Schuba" fullname="Christoph Schuba">
<organization/>
</author>
<date year="1993" month="August"/>
</front>
</reference>
<reference anchor="C11"> <reference anchor="TBIT" target="https://www.icir.org/tbit/">
<front> <front>
<title>Information technology - Programming <title>TBIT, the TCP Behavior Inference Tool</title>
languages - C</title> <author>
<author initials="" surname="ISO/IEC" fullname="ISO/IEC"> <organization>TBIT</organization>
<organization></organization> </author>
</author> <date year="2001"/>
<date year="2011"/> </front>
</front> </reference>
<seriesInfo name="" value="ISO/IEC 9899:2011"/>
</reference>
<reference anchor="POSIX"> <reference anchor="C11">
<front> <front>
<title>IEEE Standard for Information Technology -- Portab <title>Information technology - Programming languages - C</title>
le Operating System Interface (POSIX)</title> <author>
<author initials="" surname="IEEE" fullname="IEEE"> <organization>ISO/IEC</organization>
<organization></organization> </author>
</author> <date year="2018" month="June"/>
<date year="2017"/> </front>
</front> <seriesInfo name="ISO/IEC" value="9899:2018"/>
<seriesInfo name="" value="IEEE Std 1003.1-2017"/> </reference>
</reference>
<reference anchor="ARC4RANDOM" target="https://man.openbsd.org/arc4random <reference anchor="POSIX">
"> <front>
<front> <title>IEEE Standard for Information Technology -- Portable Operatin
<title>arc4random(3)</title> g System Interface (POSIX(TM)) Base Specifications, Issue 7</title>
<author initials="" surname="OpenBSD" fullname="OpenBSD"> <author>
<organization></organization> <organization>IEEE</organization>
</author> </author>
<date year="Library Functions Manual, 2022"/> <date year="2018" month="January"/>
</front> </front>
<seriesInfo name="IEEE Std" value="1003.1-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8277153"/>
</reference>
</reference> <reference anchor="ARC4RANDOM" target="https://man.openbsd.org/arc4rando
m">
<front>
<title>arc4random(3)</title>
<author>
<organization>OpenBSD</organization>
</author>
<date month="September" year="2019"/>
</front>
<refcontent>Library Functions Manual</refcontent>
</reference>
<reference anchor="GETENTROPY" target="https://man7.org/linux/man-pages/m an3/getentropy.3.html"> <reference anchor="GETENTROPY" target="https://man7.org/linux/man-pages/m an3/getentropy.3.html">
<front> <front>
<title>getentropy(3)</title> <title>getentropy(3)</title>
<author initials="" surname="Linux" fullname="Linux"> <author>
<organization></organization> <organization>Linux</organization>
</author> </author>
<date year="Linux Programmer's Manual, 2022"/> <date month="March" year="2021"/>
</front> </front>
<refcontent>Linux Programmer's Manual</refcontent>
</reference> </reference>
<reference anchor="CVEs" target="https://www.gont.com.ar/miscellanea/prng
-cves/">
<front>
<title>Vulnerability Advisories for Pseudo Random Number
Generators</title>
<author initials="" surname="NVD" fullname="NVD">
<organization></organization>
</author>
<date year="2022"/>
</front>
</reference>
<reference anchor="Zalewski2012" target="https://lcamtuf.coredump.cx/p0f.
shtml">
<front>
<title>p0f v3 (version 3.09b)</title>
<author initials="M." surname="Zalewski" fullname="M. Zal
ewski">
<organization></organization>
</author>
<date year="2012"/>
</front>
</reference>
<!-- HMAC -->
<?rfc include="reference.RFC.2104" ?>
<!-- md5 -->
<!-- <?rfc include="reference.RFC.6151" ?> -->
<!-- flow label -->
<?rfc include="reference.RFC.7098" ?>
<!-- MD5
<?rfc include="reference.RFC.1321" ?>
<!-- Pervasive Monitoring --> <reference anchor="CVEs" target="https://www.gont.com.ar/miscellanea/prn
<?rfc include="reference.RFC.7258" ?> g-cves/">
<front>
<title>Vulnerability Advisories for PRNGs</title>
<author>
<organization>NVD</organization>
</author>
</front>
</reference>
<!-- TCP ISNs --> <reference anchor="Zalewski2012" target="https://lcamtuf.coredump.cx/p0f
<!-- .shtml">
<?rfc include="reference.RFC.1948" ?> <front>
<reference anchor="CPNI-TCP" target="https://www.gont.com.ar/papers/tn-03 <title>p0f v3 (3.09b)</title>
-09-security-assessment-TCP.pdf"> <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
<front> <organization/>
<title>Security Assessment of the Transmission Control Pr </author>
otocol (TCP)</title> </front>
<author initials="F." surname="Gont" fullname= "Fernando </reference>
Gont">
<organization></organization>
</author>
<date year="2009"/>
</front>
<seriesInfo name="" value="United Kingdom's Centre for the Protec
tion of National Infrastructure (CPNI) Technical Report"/>
</reference>
<reference anchor="Zalewski2001" target="https://lcamtuf.coredump.cx/oldt <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
cp/tcpseq.html"> 04.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.70
<title>Strange Attractors and TCP/IP Sequence Number Anal 98.xml"/>
ysis</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72
<author initials="M." surname="Zalewski" fullname="M. Zal 58.xml"/>
ewski"> <reference anchor="CPNI-TCP" target="https://www.si6networks.com/files/pu
<organization></organization> blications/tn-03-09-security-assessment-TCP.pdf">
</author> <front>
<date year="2001"/> <title>Security Assessment of the Transmission Control Protocol (TCP
</front> )</title>
</reference> <author>
<organization>Centre for the Protection of National Infrastructure
(CPNI)</organization>
</author>
<date month="February" year="2009"/>
</front>
<seriesInfo name="CPNI Technical Note" value="3/2009"/>
</reference>
<reference anchor="Zalewski2002" target="https://lcamtuf.coredump.cx/newt <reference anchor="Zalewski2001" target="https://lcamtuf.coredump.cx/old
cp/"> tcp/tcpseq.html">
<front> <front>
<title>Strange Attractors and TCP/IP Sequence Number Anal <title>Strange Attractors and TCP/IP Sequence Number Analysis</title
ysis - One Year Later</title> >
<author initials="M." surname="Zalewski" fullname="M. Zal <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
ewski"> <organization/>
<organization></organization> </author>
</author> <date year="2001" month="April"/>
<date year="2001"/> </front>
</front> </reference>
</reference>
<!-- <reference anchor="Zalewski2002" target="https://lcamtuf.coredump.cx/new
<reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb tcp/">
/papers/ipext.pdf"> <front>
<front> <title>Strange Attractors and TCP/IP Sequence Number Analysis - One
<title>Security Problems in the TCP/IP Protocol Suite</ti Year Later (2002)</title>
tle> <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
<author initials="S." surname="Bellovin" fullname="Bellov <organization/>
in"> </author>
<organization></organization> </front>
</author> </reference>
<date year="Computer Communications Review, vol. 19, no.
2, pp. 32-48, 1989"/>
</front>
</reference>
<reference anchor="Joncheray1995" target="https://www.usenix.org/legacy/p ublications/library/proceedings/security95/full_papers/joncheray.pdf"> <reference anchor="Joncheray1995" target="https://www.usenix.org/legacy/p ublications/library/proceedings/security95/full_papers/joncheray.pdf">
<front> <front>
<title>A Simple Active Attack Against TCP</title> <title>Simple Active Attack Against TCP</title>
<author initials="L." surname="Joncheray" fullname="L. Jo <author initials="L." surname="Joncheray" fullname="Laurent Jonchera
ncheray"> y">
<organization></organization> <organization/>
</author> </author>
<date year="Proc. Fifth Usenix UNIX Security Symposium, 1 <date year="1995" month="June"/>
995"/> </front>
</front> <refcontent>Proceedings of the Fifth USENIX UNIX Security Symposium</re
</reference> fcontent>
</reference>
<reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/pa
pers/117.pdf">
<front>
<title>A Weakness in the 4.2BSD UNIX TCP/IP Software</tit
le>
<author initials="R." surname="Morris" fullname="Robert M
orris">
<organization></organization>
</author>
<date year="1985"/>
</front>
<seriesInfo name="CSTR 117," value="AT&amp;T Bell Laboratories, M
urray Hill, NJ"/>
</reference>
<!--
<reference anchor="USCERT2001" target="https://www.kb.cert.org/vuls/id/49
8440">
<front>
<title>US-CERT Vulnerability Note VU#498440: Multiple TCP
/IP implementations may use statistically predictable initial sequence numbers
</title>
<author initials="" surname="US-CERT" fullname= "US-CERT"
>
<organization></organization>
</author>
<date year="2001"/>
</front>
</reference>
<!--
<reference anchor="CERT2001" target="https://www.cert.org/advisories/CA-2
001-09.html">
<front>
<title>CERT Advisory CA-2001-09: Statistical Weaknesses i
n TCP/IP Initial Sequence Numbers
</title>
<author initials="" surname="CERT" fullname= "CERT">
<organization></organization>
</author>
<date year="2001"/>
</front>
</reference>
<reference anchor="Shimomura1995" target="https://www.gont.com.ar/docs/po
st-shimomura-usenet.txt">
<front>
<title>Technical details of the attack described by Marko
ff in NYT</title>
<author initials="T." surname="Shimomura" fullname= "Tsut
omu Shimomura">
<organization></organization>
</author>
<date year="1995"/>
</front>
<seriesInfo name="Message posted in USENET's comp.security.misc n
ewsgroup" value=" Message-ID: &lt;3g5gkl$5j1@ariel.sdsc.edu&gt;"/>
</reference>
<!-- ICMP attacks -->
<?rfc include="reference.RFC.5927" ?>
<!-- TCP based attacks -->
<?rfc include="reference.RFC.4953" ?>
<!-- TLS -->
<?rfc include="reference.RFC.8446" ?>
<!-- SEND -->
<?rfc include="reference.RFC.3971" ?>
<!-- Frag con ND -->
<?rfc include="reference.RFC.6980" ?>
<!-- IPv6 Flow Label -->
<!--
<?rfc include="reference.I-D.gont-6man-flowlabel-security" ?>
<!-- Fragment ID -->
<!--
<?rfc include="reference.I-D.ietf-6man-predictable-fragment-id" ?>
<?rfc include="reference.RFC.7739" ?>
<?rfc include="reference.RFC.4963" ?> <!-- IPv4 Reassembly Errors at High
Data Rates -->
<!-- IPv4 Security Assessment -->
<?rfc include="reference.RFC.6274" ?>
<reference anchor="Press1992">
<front>
<title>Numerical Recipes in C: The Art of Scientific Comp
uting</title>
<author initials="W. H." surname="Press" fullname="Willia
m H. Press">
<organization></organization>
</author>
<author initials="S. A." surname="Teukolsky" fullname="Sa
ul A. Teukolsky">
<organization></organization>
</author>
<author initials="W. T." surname="Vetterling" fullname="W
illiam T. Vetterling">
<organization></organization>
</author>
<author initials="B. P." surname="Flannery" fullname="Bri <reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/p
an P. Flannery"> apers/117.pdf">
<organization></organization> <front>
</author> <title>A Weakness in the 4.2BSD UNIX TCP/IP Software</title>
<author initials="R." surname="Morris" fullname="Robert T. Morris">
<organization/>
</author>
<date year="1985" month="February"/>
</front>
<refcontent>CSTR 117, AT&amp;T Bell Laboratories, Murray Hill, NJ</refc
ontent>
</reference>
<date year="2nd ed. ISBN 0-521-43108-5. Cambridge Univers <reference anchor="Shimomura1995" target="https://www.gont.com.ar/files/p
ity Press, 1992"/> ost-shimomura-usenet.txt">
</front> <front>
</reference> <title>Technical details of the attack described by Markoff in NYT</
title>
<author initials="T." surname="Shimomura" fullname="Tsutomu Shimomur
a">
<organization/>
</author>
<date day="25" year="1995" month="January"/>
</front>
<refcontent>message to the USENET comp.security.misc newsgroup</refcon
tent>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
27.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.49
53.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
71.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
80.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
39.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
963.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
74.xml"/>
<reference anchor="Romailler2020" target="https://research.kudelskisecuri <reference anchor="Press1992">
ty.com/2020/07/28/the-definitive-guide-to-modulo-bias-and-how-to-avoid-it/"> <front>
<front> <title>Numerical Recipes in C: The Art of Scientific Computing</titl
<title>THE DEFINITIVE GUIDE TO "MODULO BIAS AND HOW TO AV e>
OID IT"!</title> <author initials="W." surname="Press" fullname="William H. Press">
<author initials="Y." surname="Romailler" fullname="Yolan <organization/>
Romailler"> </author>
<organization></organization> <author initials="S." surname="Teukolsky" fullname="Saul A. Teukolsk
</author> y">
<date year="Kudelski Security Research, 2020"/> <organization/>
</front> </author>
</reference> <author initials="W." surname="Vetterling" fullname="William T. Ve
tterling">
<organization/>
</author>
<author initials="B." surname="Flannery" fullname="Brian P. Flannery
">
<organization/>
</author>
<date month="December" year="1992"/>
</front>
<seriesInfo name="ISBN" value="0-521-43108-5"/>
<refcontent>2nd Ed., Cambridge University Press</refcontent>
</reference>
<reference anchor="Aumasson2018"> <reference anchor="Romailler2020" target="https://research.kudelskisecur
<front> ity.com/2020/07/28/the-definitive-guide-to-modulo-bias-and-how-to-avoid-it/">
<title>Serious Cryptography: A Practical Introduction to <front>
Modern Encryption</title> <title>The Definitive Guide to "Modulo Bias and How to Avoid It"!</t
<author initials="J.P." surname="Aumasson" fullname="Jean itle>
-Philippe Aumasson"> <author initials="Y." surname="Romailler" fullname="Yolan Romailler"
<organization></organization> >
</author> <organization/>
<date year="ISBN-10: 1-59327-826-8, No Starch Press, Inc. </author>
, 2018"/> <date month="July" year="2020"/>
</front> </front>
</reference> <refcontent>Kudelski Security Research</refcontent>
</reference>
<reference anchor="Knuth1983"> <reference anchor="Aumasson2018">
<front> <front>
<title>The Art of Computer Programming</title> <title>Serious Cryptography: A Practical Introduction to Modern Encr
<author initials="D." surname="Knuth" fullname="Donald Kn yption</title>
uth"> <author initials="J-P." surname="Aumasson" fullname="Jean-Philippe A
<organization></organization> umasson">
</author> <organization/>
<date year="volume 2 (Seminumerical Algorithms), 2nd ed. </author>
Reading, Massachusetts: Addison-Wesley Publishing Company, 1981"/> <date month="November" year="2017"/>
</front> </front>
</reference> <seriesInfo name="ISBN-10" value="1-59327-826-8"/>
<refcontent>No Starch Press, Inc.</refcontent>
</reference>
<reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb <reference anchor="Knuth1983">
/papers/ipext.pdf"> <front>
<front> <title>The Art of Computer Programming</title>
<title>Security Problems in the TCP/IP Protocol Suite</ti <author initials="D." surname="Knuth" fullname="Donald Knuth">
tle> <organization/>
<author initials="S." surname="Bellovin" fullname="Bellov </author>
in"> <date year="1981" month="January"/>
<organization></organization> </front>
</author> <refcontent>Volume 2 (Seminumerical Algorithms), 2nd Ed., Reading, Mass
<date year="Computer Communications Review, vol. 19, no. achusetts, Addison-Wesley Publishing Company</refcontent>
2, pp. 32-48, 1989"/> </reference>
</front>
</reference>
<reference anchor="Bellovin2002" target="https://www.cs.columbia.edu/~smb <reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~sm
/papers/fnat.pdf"> b/papers/ipext.pdf">
<front> <front>
<title>A Technique for Counting NATted Hosts</title> <title>Security Problems in the TCP/IP Protocol Suite</title>
<author initials="S. M." surname="Bellovin" fullname= "Be <author initials="S." surname="Bellovin" fullname="Steven M. Bellovi
llovin, S. M."> n">
<organization></organization> <organization/>
</author> </author>
<date year="2002"/> <date month="April" year="1989"/>
</front> </front>
<seriesInfo name="IMW'02" value="Nov. 6-8, 2002, Marseille, Franc <refcontent>Computer Communications Review, Vol. 19, No. 2, pp. 32-48</
e"/> refcontent>
</reference> </reference>
<reference anchor="Fyodor2003" target="https://nmap.org/presentations/Can <reference anchor="Bellovin2002" target="https://www.cs.columbia.edu/~sm
SecWest03/CD_Content/idlescan_paper/idlescan.html"> b/papers/fnat.pdf">
<front> <front>
<title>Idle scanning and related IP ID games</title> <title>A Technique for Counting NATted Hosts</title>
<author initials="" surname="Fyodor" fullname= "Fyodor"> <author initials="S." surname="Bellovin" fullname="Steven M. Bellovi
<organization></organization> n">
</author> <organization/>
<date year="2003"/> </author>
</front> <date year="2002" month="November"/>
</reference> </front>
<seriesInfo name="ISBN" value="1-58113-603-X/02/0011"/>
<refcontent>IMW'02, Marseille, France</refcontent>
</reference>
<reference anchor="Sanfilippo1998a" target="http://seclists.org/bugtraq/1 <reference anchor="Fyodor2003" target="https://nmap.org/presentations/Ca
998/Dec/48"> nSecWest03/CD_Content/idlescan_paper/idlescan.html">
<front> <front>
<title>about the ip header id</title> <title>Idle Scanning and related IPID games</title>
<author initials="S." surname="Sanfilippo" fullname="S. S <author>
anfilippo"> <organization>Fyodor</organization>
<organization></organization> </author>
</author> <date year="2003"/>
<date/> </front>
</front> </reference>
<seriesInfo name="Post to Bugtraq mailing-list," value="Mon Dec 1
4 1998" />
</reference>
<reference anchor="Sanfilippo1998b" target="https://github.com/antirez/hp <reference anchor="Sanfilippo1998a" target="http://seclists.org/bugtraq/
ing/raw/master/docs/SPOOFED_SCAN.txt"> 1998/Dec/48">
<front> <front>
<title>Idle scan</title> <title>about the ip header id</title>
<author initials="S." surname="Sanfilippo" fullname="S. S <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfi
anfilippo"> lippo">
<organization></organization> <organization/>
</author> </author>
<date year="1998"/> <date month="December" year="1998"/>
</front> </front>
<seriesInfo name="Post to Bugtraq" value="mailing-list" /> <refcontent>message to the Bugtraq mailing list</refcontent>
</reference> </reference>
<reference anchor="Sanfilippo1999" target="https://github.com/antirez/hpi <reference anchor="Sanfilippo1998b" target="https://seclists.org/bugtraq
ng/raw/master/docs/MORE-FUN-WITH-IPID"> /1998/Dec/79">
<front> <front>
<title>more ip id</title> <title>new tcp scan method</title>
<author initials="S." surname="Sanfilippo" fullname="S. S <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfi
anfilippo"> lippo">
<organization></organization> <organization/>
</author> </author>
<date year="1999"/> <date year="1998" month="December" day="18"/>
</front> </front>
<seriesInfo name="Post to Bugtraq" value="mailing-list" /> <refcontent>message to the Bugtraq mailing list</refcontent>
</reference> </reference>
<reference anchor="Silbersack2005" target="https://citeseerx.ist.psu.edu/ <reference anchor="Sanfilippo1999" target="https://github.com/antirez/hp
viewdoc/download?doi=10.1.1.91.4542&amp;rep=rep1&amp;type=pdf"> ing/raw/master/docs/MORE-FUN-WITH-IPID">
<front> <front>
<title>Improving TCP/IP security through randomization wi <title>more ip id</title>
thout sacrificing interoperability</title> <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfi
<author initials="M.J." surname="Silbersack" fullname="Mi lippo">
chael James Silbersack"> <organization/>
<organization>The FreeBSD Project</organization> </author>
</author> <date year="1999" month="November"/>
<date year="2005"/> </front>
</front> <refcontent>message to the Bugtraq mailing list</refcontent>
<seriesInfo name="EuroBSDCon 2005" value="Conference"/> </reference>
</reference>
<!-- <reference anchor="Silbersack2005" target="https://www.silby.com/eurobsd
<reference anchor="Zalewski2003" target="http://lcamtuf.coredump.cx/ipfra con05/eurobsdcon_silbersack.pdf">
g.txt"> <front>
<front> <title>Improving TCP/IP security through randomization without sacri
<title>A new TCP/IP blind data injection technique?</titl ficing interoperability</title>
e> <author initials="M." surname="Silbersack" fullname="Michael James S
<author initials="M." surname="Zalewski" fullname="M. Zal ilbersack">
ewski"> <organization>The FreeBSD Project</organization>
<organization></organization> </author>
</author> </front>
<date year="2003"/> <refcontent>EuroBSDCon 2005 Conference</refcontent>
</front> </reference>
</reference>
<reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/ papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln erability.pdf"> <reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/ papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln erability.pdf">
<front> <front>
<title>OpenBSD DNS Cache Poisoning and Multiple O/S Predi <title>OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP I
ctable IP ID Vulnerability</title> D Vulnerability</title>
<author initials="A." surname="Klein" fullname="Amit Klei <author initials="A." surname="Klein" fullname="Amit Klein">
n"> <organization/>
<organization></organization> </author>
</author> <date month="November" year="2007"/>
<date year="2007"/> </front>
</front> </reference>
</reference>
<reference anchor="IPID-DEV" target="https://arxiv.org/pdf/1906.10478.pdf
">
<front>
<title>From IP ID to Device ID and KASLR Bypass (Extended
Version)</title>
<author initials="A." surname="Klein" fullname="Amit Klei
n">
<organization></organization>
</author>
<author initials="B." surname="Pinkas" fullname="Benny Pi
nkas">
<organization></organization>
</author>
<date year="2019" month="June"/>
</front>
<!--
<seriesInfo name="Journal of Research of the National Institute o
f Standards and Technology" value="Volume 121" />
</reference>
<!--
<reference anchor="Gont2011">
<front>
<title>Hacking IPv6 Networks (training course)</title>
<author initials="F." surname="Gont" fullname="Fernando G
ont">
<organization></organization>
</author>
<date month="June" year="2011"/>
</front>
<seriesInfo name="Hack In Paris 2011 Conference" value="P
aris, France"/>
</reference>
<!-- <reference anchor="IPID-DEV" target="https://arxiv.org/pdf/1906.10478.pd
<reference anchor="Gont2012"> f">
<front> <front>
<title>Recent Advances in IPv6 Security</title> <title>From IP ID to Device ID and KASLR Bypass (Extended Version)</
<author initials="F." surname="Gont" fullname="Fernando G title>
ont"> <author initials="A." surname="Klein" fullname="Amit Klein">
<organization></organization> <organization/>
</author> </author>
<date month="May" year="2012"/> <author initials="B." surname="Pinkas" fullname="Benny Pinkas">
</front> <organization/>
<seriesInfo name="BSDCan 2012 Conference" value="Ottawa, </author>
Canada. May 11-12, 2012"/> <date year="2019" month="October"/>
</front>
<seriesInfo name="DOI" value="10.48550/arXiv.1906.10478"/>
</reference> </reference>
<!-- IPv6 addresses -->
<?rfc include="reference.I-D.irtf-pearg-numeric-ids-history" ?>
<?rfc include="reference.I-D.gont-numeric-ids-sec-considerations" ?>
<!-- <reference anchor='RFC9414' target='https://www.rfc-editor.org/info/rfc9414'>
<?rfc include="reference.I-D.ietf-6man-default-iids" ?> <front>
<title>Unfortunate History of Transient Numeric Identifiers</title>
<?rfc include="reference.RFC.7721" ?> <author initials='F' surname='Gont' fullname='Fernando Gont'>
<?rfc include="reference.RFC.7707" ?> <organization />
</author>
<!-- CSPRNG --> <author initials='I' surname='Arce' fullname='Ivan Arce'>
<?rfc include="reference.RFC.8937" ?> <organization />
</author>
<date year='2023' month='July'/>
</front>
<seriesInfo name="RFC" value="9414"/>
<seriesInfo name="DOI" value="10.17487/RFC9414"/>
</reference>
<reference anchor="TCPT-uptime" target="https://securiteam.com/securityne <reference anchor='RFC9416' target='https://www.rfc-editor.org/info/rfc9416'>
ws/5np0c153pi/"> <front>
<front> <title>Security Considerations for Transient Numeric Identifiers Employed in Net
<title>TCP Timestamping - Obtaining System Uptime Remotel work Protocols</title>
y</title> <author initials='F' surname='Gont' fullname='Fernando Gont'>
<author initials="B." surname="McDanel" fullname="B. McDa <organization />
nel"> </author>
<organization>Securiteam</organization> <author initials='I' surname='Arce' fullname='Ivan Arce'>
</author> <organization />
<date month="March" day="14" year="2001"/> </author>
</front> <date year='2023' month='July'/>
</front>
<seriesInfo name="BCP" value="72"/>
<seriesInfo name="RFC" value="9416"/>
<seriesInfo name="DOI" value="10.17487/RFC9416"/>
</reference>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
21.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
707.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
37.xml"/>
<!-- SipHash OLD <reference anchor="TCPT-uptime" target="https://seclists.org/bugtraq/200
<reference anchor="SipHash" target="https://www.aumasson.jp/siphash/sipha 1/Mar/182">
sh.pdf"> <front>
<front> <title>TCP Timestamping - Obtaining System Uptime Remotely</title>
<title>SipHash: a fast short-input PRF</title> <author initials="B." surname="McDanel" fullname="Bret McDanel">
<author initials="J. P." surname="Aumasson" fullname="Jea <organization>Securiteam</organization>
n-Philippe Aumasson"> </author>
<organization>NAGRA</organization> <date month="March" year="2001"/>
</author> </front>
<author initials="D. J." surname="Bernstein" fullname="Da <refcontent>message to the Bugtraq mailing list</refcontent>
niel J. Bernstein"> </reference>
<organization>University of Illinois at Chicago</
organization>
</author>
<date year="2012"/>
</front>
<seriesInfo name="" value="Indocrypt 2012. 13th International Con
ference on Cryptology. December 9-12, 2012"/>
</reference>
<reference anchor="SipHash" target="https://github.com/veorq/SipHash"> <reference anchor="SipHash" target="https://github.com/veorq/SipHash">
<front> <front>
<title>SipHash: a fast short-input PRF</title> <title>SipHash: a fast short-input PRF</title>
<author initials="J. P." surname="Aumasson" fullname="Jea <author>
n-Philippe Aumasson"> <organization/>
<organization>NAGRA</organization> </author>
</author> <date year="2023" month="February"/>
<author initials="D. J." surname="Bernstein" fullname="Da </front>
niel J. Bernstein"> </reference>
<organization>University of Illinois at Chicago</
organization>
</author>
<date year="2012"/>
</front>
</reference>
<reference anchor="BLAKE3" target="https://blake3.io/">
<front>
<title>BLAKE3: one function, fast everywhere</title>
<author initials="J." surname="O'Connor" fullname="Jack O
'Connor">
<organization></organization>
</author>
<author initials="J. P." surname="Aumasson" fullname="Jea
n-Philippe Aumasson">
<organization>NAGRA</organization>
</author>
<author initials="S." surname="Neves" fullname="Samuel Ne
ves">
<organization></organization>
</author>
<author initials="Z." surname="Wilcox-O'Hearn" fullname="
Zooko Wilcox-O'Hearn">
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="FIPS-SHS" target="https://nvlpubs.nist.gov/nistpubs/FI
PS/NIST.FIPS.180-4.pdf">
<front>
<title>Secure Hash Standard (SHS)</title>
<author>
<organization>NIST</organization>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="" value="Federal Information Processing Standar
ds Publication 180-4"/>
</reference>
<!-- Deprecate SHA-1 -->
<?rfc include="reference.RFC.6194" ?> <reference anchor="BLAKE3" target="https://blake3.io/">
<front>
<title>BLAKE3: one function, fast everywhere</title>
<author>
<organization/>
</author>
<date year="2022" month="September"/>
</front>
</reference>
<!-- <reference anchor="FIPS-SHS" target="https://nvlpubs.nist.gov/nistpubs/F
<reference anchor="FIPS-HMAC" target="https://nvlpubs.nist.gov/nistpubs/F IPS/NIST.FIPS.180-4.pdf">
IPS/NIST.FIPS.198-1.pdf"> <front>
<front> <title>Secure Hash Standard (SHS)</title>
<title>The Keyed-Hash Message Authentication Code (HMAC)) <author>
</title> <organization>NIST</organization>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.61
<organization>NIST</organization> 94.xml"/>
</author>
<date month="July" year="2008"/>
</front>
<seriesInfo name="" value="Federal Information Processing Standar
ds Publication 198-1"/>
</reference>
</references> </references>
</references>
<section anchor="fawed-algorithms" numbered="true" toc="default">
<name>Algorithms and Techniques with Known Issues</name>
<t>The following subsections discuss algorithms and techniques with known
negative security and privacy implications.
<section title="Algorithms and Techniques with Known Issues" anchor="fawed-algor
ithms">
<t>The following subsections discuss algorithms and techniques with known negati
ve security and privacy implications.
<list style="hanging">
<t hangText="NOTE:">
<vspace blankLines="0"/>
As discussed in <xref target="intro"/>, the use of cryptographic techniques migh
t allow for the safe use of some of these algorithms and techniques. However, th
is should be evaluated on a case by case basis.
</t> </t>
</list> <aside><t>NOTE: As discussed in <xref target="intro" format="default"/>,
</t> the use of cryptographic techniques might allow for the safe use of some of the
se algorithms and techniques. However, this should be evaluated on a case-by-cas
<section title="Predictable Linear Identifiers Algorithm" anchor="trad_selection e basis.
"> </t></aside>
<t>One of the most trivial ways to achieve uniqueness with a low identifier reus <section anchor="trad_selection" numbered="true" toc="default">
e frequency is to produce a linear sequence. This type of algorithm has been emp <name>Predictable Linear Identifiers Algorithm</name>
loyed in the past to generate identifiers of Categories #1, #2, and #4 (please s <t>One of the most trivial ways to achieve uniqueness with a low identif
ee <xref target="categorizing"/> for an analysis of these categories). <!-- This ier reuse frequency is to produce a linear sequence. This type of algorithm has
obviously assumes that each identifier will be used for a similar period of tim been employed in the past to generate identifiers of Categories #1, #2, and #4 (
e.--></t> please see <xref target="categorizing" format="default"/> for an analysis of the
se categories).
<t> </t>
For example, the following algorithm has been employed (see e.g. <xref target="M <t>
orris1985"/>, <xref target="Shimomura1995"/>, <xref target="Silbersack2005"/> an For example, the following algorithm has been employed (see, e.g., <xref target=
d <xref target="CPNI-TCP"/>) in a number of operating systems for selecting IP f "Morris1985" format="default"/>, <xref target="Shimomura1995" format="default"/>
ragment IDs, TCP ephemeral ports, etc.:</t> , <xref target="Silbersack2005" format="default"/>, and <xref target="CPNI-TCP"
format="default"/>) in a number of operating systems for selecting IP IDs, TCP e
<t> phemeral port numbers, etc.:</t>
<figure> <sourcecode type="c"><![CDATA[
<artwork>
/* Initialization code */ /* Initialization code */
next_id = min_id; next_id = min_id;
id_inc= 1; id_inc= 1;
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
retry = id_range; retry = id_range;
skipping to change at line 1768 skipping to change at line 1305
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry--; retry--;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
</artwork> ]]></sourcecode>
</figure> <t>NOTE:</t>
</t>
<t> <t indent="3">suitable_id() checks whether a candidate numeric identifier is sui
<list style="hanging"> table (e.g., whether it is unique or not).
<t hangText="NOTE:">
<vspace blankLines="0"/>
suitable_id() is a function that checks whether the resulting identifier is acce
ptable (e.g., whether it's in use, etc.).
</t>
</list>
</t> </t>
<t>For obvious reasons, this algorithm results in predictable sequences.
<t>For obvious reasons, this algorithm results in predictable sequences. Since a Since a global counter is used to generate the transient numeric identifiers ("
global counter is used to generate the transient numeric identifiers ("next_id" next_id" in the example above), an entity that learns one numeric identifier can
in the example above), an entity that learns one numeric identifier can infer p infer past numeric identifiers and predict future values to be generated by the
ast numeric identifiers and predict future values to be generated by the same al same algorithm. Since the value employed for the increments is known (such as "
gorithm. Since the value employed for the increments is known (such as "1" in th 1" in this case), an attacker can sample two values and learn the number of iden
is case), an attacker can sample two values, and learn the number of identifiers tifiers that were generated in between the two sampled values. Furthermore, if t
that have been were generated in-between the two sampled values. Furthermore, i he counter is initialized, to some known value (e.g., when the system is bootstr
f the counter is initialized e.g. when the system its bootstrapped to some known apped), the algorithm will leak additional information, such as the number of tr
value, the algorithm will leak additional information, such as the number of tr ansmitted fragmented datagrams in the case of an IP ID generator <xref target="S
ansmitted fragmented datagrams in the case of an IP ID generator <xref target="S anfilippo1998a" format="default"/> or the system uptime in the case of TCP times
anfilippo1998a"/>, or the system uptime in the case of TCP timestamps <xref targ tamps <xref target="TCPT-uptime" format="default"/>.
et="TCPT-uptime"/>.
</t> </t>
</section>
</section> <section anchor="random-increments" numbered="true" toc="default">
<name>Random-Increments Algorithm</name>
<section title="Random-Increments Algorithm" anchor="random-increments"> <t>This algorithm offers a middle ground between the algorithms that
<t>This algorithm offers a middle ground between the algorithms that generate randomized transient numeric identifiers (such as those described in
generate randomized transient numeric identifiers (such as those described in Sections <xref target="simple-randomization" format="counter"/> and <xref target
<xref target="simple-randomization"/> and <xref target="simple-randomization2"/ ="simple-randomization2" format="counter"/>) and those that generate identifiers
>), and those that generate identifiers with a predictable monotonically-increas with a predictable monotonically increasing function (see <xref target="trad_se
ing function (see <xref target="trad_selection"/>). lection" format="default"/>).
</t> </t>
<t> <sourcecode type="c"><![CDATA[
<figure>
<artwork>
/* Initialization code */ /* Initialization code */
next_id = random(); /* Initialization value */ next_id = random(); /* Initialization value */
id_rinc = 500; /* Determines the trade-off */ id_rinc = 500; /* Determines the trade-off */
/* Transient Numeric ID selection function */ /* Transient Numeric ID selection function */
id_range = max_id - min_id + 1; id_range = max_id - min_id + 1;
retry = id_range; retry = id_range;
skipping to change at line 1823 skipping to change at line 1349
if (suitable_id(next_id)) { if (suitable_id(next_id)) {
return next_id; return next_id;
} }
retry = retry - id_inc; retry = retry - id_inc;
} while (retry > 0); } while (retry > 0);
return ERROR; return ERROR;
]]></sourcecode>
</artwork> <t>NOTE:</t>
</figure> <t indent="3">random() is a PRNG that returns a pseudorandom unsigned i
</t> nteger number of appropriate size. Beware that "adapting" the length of the outp
ut of random() with a modulo operator (e.g., C language's "%") may change the di
<t> stribution of the PRNG. To preserve a uniform distribution, the rejection sampli
This algorithm aims at producing a global monotonically-increasing sequence of t ng technique <xref target="Romailler2020" format="default"/> can be used.</t>
ransient numeric identifiers, while avoiding the
use of fixed increments, which would lead to trivially predictable sequences. T
he value "id_inc" allows for direct control of the trade-off between unpredictab
ility and identifier reuse frequency. The smaller the value of &quot;id_inc&quot
;, the more similar this algorithm is to a predicable, global linear ID generati
on algorithm (as the one in <xref target="trad_selection"/>). The larger the val
ue of "id_inc", the more similar this algorithm is to the algorithm described in
<xref target="simple-randomization"/> of this document.</t>
<t> <t indent="3">suitable_id() is a function that checks whether a candidate iden
When the identifiers wrap, there is a risk of collisions of transient numeric id tifier is suitable (e.g., whether it is unique or not).
entifiers (i.e., identifier reuse). Therefore, "id_inc" should be selected accor
ding to the following criteria:
</t> </t>
<t> <t>
<list style="symbols"> This algorithm aims at producing a global monotonically increasing sequence of t
<t>It should maximize the wrapping time of the identifier space.</t> ransient numeric identifiers while avoiding the
<t>It should minimize identifier reuse frequency.</t> use of fixed increments, which would lead to trivially predictable sequences. T
<t>It should maximize unpredictability.</t> he value "id_rinc" allows for direct control of the trade-off between unpredicta
</list> bility and identifier reuse frequency. The smaller the value of "id_rinc", the m
</t> ore similar this algorithm is to a predicable, global linear identifier generati
on algorithm (as the one in <xref target="trad_selection" format="default"/>). T
<t> he larger the value of "id_rinc", the more similar this algorithm is to the algo
Clearly, these are competing goals, and the decision of which value of "id_inc" rithm described in <xref target="simple-randomization" format="default"/> of thi
to use is a trade-off. Therefore, the value of "id_inc" is at times a configurab s document.</t>
le parameter so that system administrators can make the trade-off for themselves <t>
. We note that the alternative algorithms discussed throughout this document off When the identifiers wrap, there is a risk of collisions of transient numeric id
er better interoperability, security and privacy properties than this algorithm, entifiers (i.e., identifier reuse). Therefore, "id_rinc" should be selected acco
and hence implementation of this algorithm is discouraged. rding to the following criteria:
</t> </t>
</section> <ul spacing="normal">
<li>It should maximize the wrapping time of the identifier space.</li>
<section title="Re-using Identifiers Across Different Contexts" anchor="reuse-ac <li>It should minimize identifier reuse frequency.</li>
ross-context"> <li>It should maximize unpredictability.</li>
</ul>
<t>Employing the same identifier across contexts in which stability is not requi <t>
red (i.e. overloading the semantics of transient numeric identifier) usually has Clearly, these are competing goals, and the decision of which value of "id_rinc"
negative security and privacy implications.</t> to use is a trade-off. Therefore, the value of "id_rinc" is at times a configur
able parameter so that system administrators can make the trade-off for themselv
<t>For example, in order to generate transient numeric identifiers of Category # es. We note that the alternative algorithms discussed throughout this document o
2 or Category #3, an implementation or specification might be tempted to employ ffer better interoperability, security, and privacy properties than this algorit
a source for the numeric identifiers which is known to provide unique values, bu hm, and hence, implementation of this algorithm is discouraged.
t that may also be predictable or leak information related to the entity generat
ing the identifier. This technique has been employed in the past for e.g. genera
ting IPv6 IIDs by re-using the MAC address of the underlying network interface.
However, as noted in <xref target="RFC7721"/> and <xref target="RFC7707"/>, embe
dding link-layer addresses in IPv6 IIDs not only results in predictable values,
but also leaks information about the manufacturer of the underlying network inte
rface card, allows for network activity correlation, and makes address-based sca
nning attacks feasible.
</t> </t>
</section>
</section> <section anchor="reuse-across-context" numbered="true" toc="default">
</section> <name>Reusing Identifiers Across Different Contexts</name>
<t>Employing the same identifier across contexts in which stability is n
ot required (i.e., overloading the semantics of transient numeric identifiers) u
sually has negative security and privacy implications.</t>
<t>For example, in order to generate transient numeric identifiers of Ca
tegory #2 or #3, an implementation or specification might be tempted to employ a
source for the numeric identifiers that is known to provide unique values but t
hat may also be predictable or leak information related to the entity generating
the identifier. This technique has been employed in the past for, e.g., generat
ing IPv6 IIDs by reusing the MAC address of the underlying network interface car
d. However, as noted in <xref target="RFC7721" format="default"/> and <xref targ
et="RFC7707" format="default"/>, embedding link-layer addresses in IPv6 IIDs not
only results in predictable values but also leaks information about the manufac
turer of the underlying network interface card, allows for network activity corr
elation, and makes address-based scanning attacks feasible.
</t>
</section>
</section>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank (in alphabetical order) <contact fullna
me="Bernard Aboba"/>, <contact fullname="Jean-Philippe Aumasson"/>, <contact ful
lname="Steven Bellovin"/>, <contact fullname="Luis León Cárdenas Graide"/>, <con
tact fullname="Spencer Dawkins"/>, <contact fullname="Theo de Raadt"/>, <contact
fullname="Guillermo Gont"/>, <contact fullname="Joseph Lorenzo Hall"/>, <contac
t fullname="Gre Norcie"/>, <contact fullname="Colin Perkins"/>, <contact fullnam
e="Vincent Roca"/>, <contact fullname="Shivan Sahib"/>, <contact fullname="Rich
Salz"/>, <contact fullname="Martin Thomson"/>, and <contact fullname="Michael Tü
xen"/> for providing valuable comments on earlier draft versions of this documen
t.</t>
<t>The authors would like to thank <contact fullname="Shivan Sahib"/> and
<contact fullname="Christopher Wood"/> for their guidance during the publication
process of this document.</t>
<t>The authors would like to thank <contact fullname="Jean-Philippe Aumass
on"/> and <contact fullname="Mathew D. Green"/> (John Hopkins University) for ki
ndly answering a number of questions.</t>
<t>The authors would like to thank <contact fullname="Diego Armando Marado
na"/> for his magic and inspiration.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 195 change blocks. 
2296 lines changed or deleted 1805 lines changed or added

This html diff was produced by rfcdiff 1.48.