rfc9416xml2.original.xml   rfc9416.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 --> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. --> <!-- OPTIONS, known as processing instructions (PIs) go here. -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="no" ?>
<rfc category="bcp" docName="draft-gont-numeric-ids-sec-considerations-11" ipr="
trust200902" updates="3552">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<title abbrev="Security Considerations for IDs">Security Considerations for Tran bcp" consensus="true" docName="draft-gont-numeric-ids-sec-considerations-11" num
sient Numeric Identifiers Employed in Network Protocols</title> ber="9416" ipr="trust200902" updates="3552" obsoletes="" xml:lang="en" tocInclud
e="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.16.0 -->
<front>
<title abbrev="Security Considerations for IDs">Security Considerations for
Transient Numeric Identifiers Employed in Network Protocols</title>
<seriesInfo name="RFC" value="9416"/>
<seriesInfo name="BCP" value="72"/>
<author fullname="Fernando Gont" initials="F." surname="Gont"> <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"/>
<date/> <area>sec</area>
<!-- <keyword>security</keyword>
<area>Internet</area> <keyword>vulnerability</keyword>
<workgroup>Dynamic Host Configuration (dhc)</workgroup> <keyword>algorithm</keyword>
<!-- <area/> --> <keyword>attack</keyword>
<!-- <workgroup/> --> <keyword>fingerprinting</keyword>
<abstract> <abstract>
<t> <t>
Poor selection of transient numerical identifiers in protocols such as the TCP/I Poor selection of transient numerical identifiers in protocols such as the TCP/I
P suite has historically led to a number of attacks on implementations, ranging P suite has historically led to a number of attacks on implementations, ranging
from Denial of Service (DoS) to data injection and information leakage that can from Denial of Service (DoS) or data injection to information leakages that can
be exploited by pervasive monitoring. Due diligence in the specification of tran be exploited by pervasive monitoring. Due diligence in the specification of tran
sient numeric identifiers is required even when cryptographic techniques are emp sient numeric identifiers is required even when cryptographic techniques are emp
loyed, since these techniques might not mitigate all the associated issues. This loyed, since these techniques might not mitigate all the associated issues. This
document formally updates RFC 3552, incorporating requirements for transient nu document formally updates RFC 3552, incorporating requirements for transient nu
meric identifiers, to prevent flaws in future protocols and implementations. meric identifiers, to prevent flaws in future protocols and implementations.
</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 <xref tar
get="RFC9415" format="default"/>.</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> ave been subject to a variety of attacks, with effects ranging from Denial of Se
Network protocols employ a variety of transient numeric identifiers for differen rvice (DoS) or data injection to information leakages that could be exploited fo
t protocol entities, ranging from DNS Transaction IDs (TxIDs) to transport proto r pervasive monitoring <xref target="RFC7258" format="default"/>. The root cause
col numbers (e.g. TCP ports) or IPv6 Interface Identifiers (IIDs). These identif of these issues has been, in many cases, the poor selection of transient numeri
iers usually have specific properties that must be satisfied such that they do n c identifiers in such protocols, usually as a result of insufficient or misleadi
ot result in negative interoperability implications (e.g., uniqueness during a s ng specifications. While it is generally trivial to identify an algorithm that c
pecified period of time), and an associated failure severity when such propertie an satisfy the interoperability requirements of a given transient numeric identi
s are not met. fier, empirical evidence exists that doing so without negatively affecting the s
</t> ecurity and/or privacy properties of the aforementioned protocols is prone to er
ror <xref target="RFC9414" format="default"/>.</t>
<t>The TCP/IP protocol suite alone has been subject to variety of attacks on its <t>For example, implementations have been subject to security and/or priva
transient numeric identifiers over the past 30 years or more, with effects rang cy issues resulting from:</t>
ing from Denial of Service (DoS) or data injection, to information leakage that <ul spacing="normal">
could be exploited for pervasive monitoring <xref target="RFC7258"/>. The root o <li>predictable IPv4 or IPv6 Identification values (e.g., see <xref targ
f these issues has been, in many cases, the poor selection of identifiers in suc et="Sanfilippo1998a" format="default"/>, <xref target="RFC6274" format="default"
h protocols, usually as a result of insufficient or misleading specifications. W />, and <xref target="RFC7739" format="default"/>),</li>
hile it is generally trivial to identify an algorithm that can satisfy the inter <li>predictable IPv6 IIDs (e.g., see <xref target="RFC7217" format="defa
operability requirements for a given identifier, there exists practical evidence ult"/>, <xref target="RFC7707" format="default"/>, and <xref target="RFC7721" fo
<xref target="I-D.irtf-pearg-numeric-ids-history"/> that doing so without negat rmat="default"/>),</li>
ively affecting the security and/or privacy properties of the aforementioned pro <li>predictable transport-protocol ephemeral port numbers (e.g., see <xr
tocols is prone to error.</t> ef target="RFC6056" format="default"/> and <xref target="Silbersack2005" format=
"default"/>),</li>
<t>For example, implementations have been subject to security and/or privacy iss <li>predictable TCP Initial Sequence Numbers (ISNs) (e.g., see <xref tar
ues resulting from: get="Morris1985" format="default"/>, <xref target="Bellovin1989" format="default
"/>, and <xref target="RFC6528" format="default"/>),</li>
<list style="symbols"> <li>predictable initial timestamps in TCP timestamps options (e.g., see
<t>Predictable TCP sequence numbers (see e.g. <xref target="Morris1985"/>, <xref <xref target="TCPT-uptime" format="default"/> and <xref target="RFC7323" format=
target="Bellovin1989"/>, and <xref target="RFC6528"/>)</t> "default"/>), and</li>
<t>Predictable transport protocol numbers (see e.g. <xref target="Silbersack2005 <li>predictable DNS IDs (see, e.g., <xref target="Schuba1993" format="de
"/> and <xref target="RFC6056"/>)</t> fault"/> and <xref target="Klein2007" format="default"/>).</li>
<t>Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. <xref target="Sanfili </ul>
ppo1998a"/>, <xref target="RFC6274"/>, and <xref target="RFC7739"/>)</t>
<t>Predictable IPv6 IIDs (see e.g. <xref target="RFC7217"/>, <xref target="RFC77
07"/>, and <xref target="RFC7721"/>)</t>
<t>Predictable DNS TxIDs (see e.g. <xref target="Schuba1993"/> and <xref target=
"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 identifiers tend to be overlooked and inappropriate algorithms to generate
such identifiers are either suggested in the specification or selected by imple
menters. As a result, advice in this area is warranted.
</t>
<t>We note that the use of cryptographic techniques for confidentiality and auth
entication might not eliminate all the issues associated with predictable transi
ent numeric identifiers. Therefore, due diligence in the specification of transi
ent numeric identifiers is required even when cryptographic techniques are emplo
yed.
<list style="hanging">
<t hangText="Note:">
<vspace blankLines="0" />For example, cryptographic authentication can readily m
itigate data injection attacks even in the presence of predictable transient num
eric identifiers (such as "sequence numbers"). However, use of flawed algorithms
(such as global counters) for generating transient numeric identifiers could st
ill result in information leakages even when cryptographic techniques are employ
ed. These information leakages could in turn be leveraged to perform other devas
tating attacks (please see <xref target="I-D.irtf-pearg-numeric-ids-generation"/
> for further details).
</t>
</list>
</t>
<t><xref target="issues"/> provides an overview of common flaws in the specifica
tion of transient numeric identifiers. <xref target="vulns"/> provides an overvi
ew of the implications of predictable transient numeric identifiers. Finally, <x
ref target="reqs"/> provides key guidelines for protocol designers.
</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 identifiers may
have additional requirements or properties depending on their specific use in a
protocol. We use the term "transient numeric identifier" (or simply "numeric ide
ntifier" or "identifier" as short forms) as a generic term to refer to any data
object in a protocol specification that satisfies the identification property st
ated 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" and "hard".
</t>
<t hangText="Hard Failure:"> <t>
<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 recovered.
</t>
<t hangText="Soft Failure:"> Recent history indicates that, when new protocols are standardized or new protoc
<vspace blankLines="0" />A soft failure is a recoverable condition in which a pr ol implementations are produced, the security and privacy properties of the asso
otocol does not operate in the prescribed manner but normal operation can be res ciated transient numeric identifiers tend to be overlooked, and inappropriate al
umed automatically in a short period of time. For example, a simple packet-loss gorithms to generate such identifiers are either suggested in the specifications
event that is subsequently recovered with a retransmission can be considered a s or selected by implementers. As a result, advice in this area is warranted.
oft failure.
</t> </t>
</list> <t>We note that the use of cryptographic techniques for confidentiality an
d authentication might not eliminate all the issues associated with predictable
transient numeric identifiers. Therefore, due diligence in the specification of
transient numeric identifiers is required even when cryptographic techniques are
employed.
</t>
<aside><t>NOTE: For example, cryptographic authentication can readily mi
tigate data injection attacks even in the presence of predictable transient nume
ric identifiers (such as "sequence numbers"). However, use of flawed algorithms
(such as global counters) for generating transient numeric identifiers could sti
ll result in information leakages even when cryptographic techniques are employe
d. These information leakages could in turn be leveraged to perform other devast
ating attacks (please see <xref target="RFC9415" format="default"/> for further
details).
</t></aside>
<t><xref target="issues" format="default"/> provides an overview of common
flaws in the specification of transient numeric identifiers. <xref target="vuln
s" format="default"/> provides an overview of common flaws in the generation of
transient numeric identifiers and their associated security and privacy implicat
ions. Finally, <xref target="reqs" format="default"/> provides key guidelines fo
r protocol designers.
</t> </t>
</section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", <section anchor="terminology" numbered="true" toc="default">
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <name>Terminology</name>
"MAY", and "OPTIONAL" in this document are to be interpreted as <dl newline="true" spacing="normal">
described in BCP 14 <xref target='RFC2119' /> <xref target='RFC8174' /> wh <dt>Transient Numeric Identifier:</dt>
en, and only when, they <dd>A data object in a protocol specification that can be used to defini
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
en context. Transient numeric identifiers are usually defined as a series of bit
s and represented using integer values. These identifiers are typically dynamica
lly selected, as opposed to statically assigned numeric identifiers (e.g., see <
xref target="IANA-PROT" format="default"/>). We note that different transient nu
meric identifiers may have additional requirements or properties depending on th
eir specific use in a protocol. We use the term "transient numeric identifier" (
or simply "numeric identifier" or "identifier" as short forms) as a generic term
to refer to any data object in a protocol specification that satisfies the iden
tification property stated above.
</dd>
<dt>Failure Severity:</dt>
<dd>The interoperability consequences of a failure to comply with the in
teroperability requirements of a given identifier. Severity considers the worst
potential consequence of a failure, determined by the system damage and/or time
lost to repair the failure. In this document, we define two types of failure sev
erity: "soft" and "hard".
</dd>
<dt>Soft Failure:</dt>
<dd>A recoverable condition in which a protocol does not operate in the
prescribed manner but normal operation can be resumed automatically in a short p
eriod of time. For example, a simple packet-loss event that is subsequently reco
vered with a retransmission can be considered a soft failure.
</dd>
<dt>Hard Failure:</dt>
<dd>A non-recoverable condition in which a protocol does not operate in
the prescribed manner or it operates with excessive degradation of service. For
example, an established TCP connection that is aborted due to an error condition
constitutes, from the point of view of the transport protocol, a hard failure,
since it enters a state from which normal operation cannot be recovered.
</dd>
</dl>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>
SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bc
p14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are t
o be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target
="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
</t> </t>
</section>
<section anchor="issues" numbered="true" toc="default">
<name>Issues with the Specification of Transient Numeric Identifiers</name
>
<t>Recent work on transient numeric identifier usage in protocol specifica
tions and implementations <xref target="RFC9414" format="default"/> <xref target
="RFC9415" format="default"/> revealed that most of the issues discussed in this
document arise as a result of one of the following conditions:
</section>
<section title="Issues with the Specification of Transient Numeric Identifiers"
anchor="issues">
<t>A recent survey of transient numeric identifier usage in protocol specificati
ons and implementations <xref target="I-D.irtf-pearg-numeric-ids-history"/> reve
aled that most of the issues discussed in this document arise as a result of one
of the following conditions:
<list style="symbols">
<t>Protocol specifications that under-specify the requirements for their identif
iers</t>
<t>Protocol specifications that over-specify their identifiers</t>
<t>Protocol implementations that simply fail to comply with the specified requir
ements</t>
</list>
</t> </t>
<ul spacing="normal">
<t>Both under-specifying and over-specifying identifiers is <li>protocol specifications that under specify their transient numeric i
hazardous. TCP port numbers and sequence numbers <xref target="RFC0793"/> and dentifiers</li>
DNS TxID <li>protocol specifications that over specify their transient numeric id
<xref target="RFC1035"/> were originally under-specified, leading to implemen entifiers</li>
tations that used <li>protocol implementations that simply fail to comply with the specifi
ed requirements</li>
</ul>
<t>Both under specifying and over specifying transient numeric identifiers
is
hazardous. TCP local ports <xref target="RFC0793" format="default"/>, as well
as DNS IDs
<xref target="RFC1035" format="default"/>, were originally under specified, l
eading to implementations that resulted in
predictable values and thus were vulnerable to numerous off-path predictable values and thus were vulnerable to numerous off-path
attacks. Over-specification, as for IPv6 Interface Identifiers (IIDs) attacks. Over specification, as for IPv6 Interface Identifiers (IIDs)
<xref target="RFC4291"/> and Fragment Identification values <xref target="RFC <xref target="RFC4291" format="default"/> and IPv6 Identification values <xre
2460"/>, left f target="RFC2460" format="default"/>, left
implementations unable to respond to security and privacy issues implementations unable to respond to security and privacy issues
stemming from the mandated algorithms -- IPv6 IIDs need not expose stemming from the mandated or recommended algorithms -- IPv6 IIDs need not ex
privacy-sensitive link-layer addresses, and predictable Fragment pose
Identifiers invite the same off-path attacks that plague TCP.</t> privacy-sensitive link-layer addresses, and predictable IPv6 Fragment Header
Identification values invite the same off-path attacks that plague TCP.</t>
<t>Finally, there are protocol implementations that simply fail to comply with e <t>Finally, there are protocol implementations that simply fail to comply
xisting protocol specifications. That is, appropriate guidance is provided by th with existing protocol specifications. That is, appropriate guidance is provided
e protocol specification (whether the core specification or an update to it), bu by the protocol specification (whether it be the core specification or an updat
t an implementation simply fails to follow such guidance. For example, some popu e to it), but an implementation simply fails to follow such guidance. For exampl
lar operating systems still fail to implement transport-protocol port randomizat e, some popular operating systems still fail to implement transport-protocol por
ion, as specified in <xref target="RFC6056"/>.</t> t randomization, as specified in <xref target="RFC6056" format="default"/>.</t>
<t>Clear specification of the interoperability requirements for the transi
<t>Clear specification of the interoperability requirements for the transient nu ent numeric identifiers will help identify possible algorithms that could be emp
meric identifiers will help identify possible algorithms that could be employed loyed to generate them and also make evident if such identifiers are being over
to generate them, and also make evident if such identifiers are being over-speci specified. A protocol specification will usually also benefit from a vulnerabili
fied. A protocol specification will usually also benefit from a vulnerability as ty assessment of the transient numeric identifiers they specify to prevent the c
sessment of the transient numeric identifiers they specify, to prevent the corre orresponding considerations from being overlooked.
sponding considerations from being overlooked.
</t> </t>
</section>
</section> <section anchor="vulns" numbered="true" toc="default">
<name>Common Flaws in the Generation of Transient Numeric Identifiers</nam
<section title="Common Flaws in the Generation of Transient Numeric Identifiers" e>
anchor="vulns"> <t>This section briefly notes common flaws associated with the generation
of transient numeric identifiers. Such common flaws include, but are not limited
<t>This section briefly notes common flaws associated with the generation of tra to:
nsient numeric identifiers. Such common flaws include, but are not limited to:
<list style="symbols">
<t>Employing trivial algorithms (e.g. global counters) that result in predictabl
e identifiers</t>
<t>Employing the same identifier across contexts in which constancy is not requi
red</t>
<t>Re-using identifiers across different protocols or layers of the protocol sta
ck</t>
<t>Initializing counters or timers to constant values, when such initialization
is not required</t>
<t>Employing the same increment space across different contexts</t>
<t>Use of flawed pseudo-random number generators (PRNGs).</t>
</list>
</t> </t>
<ul spacing="normal">
<t> <li>employing trivial algorithms (e.g., global counters) that result in
predictable identifiers,</li>
<li>employing the same identifier across contexts in which constancy is
not required,</li>
<li>reusing identifiers across different protocols or layers of the prot
ocol stack,</li>
<li>initializing counters or timers to constant values when such initial
ization is not required,</li>
<li>employing the same increment space across different contexts, and</l
i>
<li>use of flawed Pseudorandom Number Generators (PRNGs).</li>
</ul>
<t>
Employing trivial algorithms for generating the identifiers means Employing trivial algorithms for generating the identifiers means
that any node that is able to sample such identifiers can easily that any node that is able to sample such identifiers can easily
predict future identifiers employed by the victim node.</t> predict future identifiers employed by the victim node.</t>
<t>
<t>
When one identifier is employed across contexts where such constancy When one identifier is employed across contexts where such constancy
is not needed, activity correlation is made possible. For is not needed, activity correlation is made possible. For
example, employing an identifier that is constant across networks example, employing an identifier that is constant across networks
allows for node tracking across networks. allows for node tracking across networks.
</t> </t>
<t>
<t> Reusing identifiers across different layers or protocols ties the
Re-using identifiers across different layers or protocols ties the security and privacy properties of the protocol reusing the identifier to the
security and privacy properties of the protocol re-using the identifier to th
e
security and privacy properties of the original identifier (over security and privacy properties of the original identifier (over
which the protocol re-using the identifier may have no control which the protocol reusing the identifier may have no control
regarding its generation). Besides, when re-using an identifier regarding its generation). Besides, when reusing an identifier
across protocols from different layers, the goal of isolating the across protocols from different layers, the goal of isolating the
properties of a layer from that of another layer is broken, and the properties of a layer from those of another layer is broken, and the
vulnerability assessment may be harder to perform, since the vulnerability assessment may be harder to perform since the
combined system, rather than each protocol in isolation will have to combined system, rather than each protocol in isolation, will have to
be assessed. be assessed.
</t> </t>
<t>
<t> At times, a protocol needs to convey order information (whether it be
At times, a protocol needs to convey order information (whether
sequence, timing, etc.). In many cases, there is no reason for the sequence, timing, etc.). In many cases, there is no reason for the
corresponding counter or timer to be initialized to any specific corresponding counter or timer to be initialized to any specific
value e.g. at system bootstrap. Similarly, there may not be a need for the di value, e.g., at system bootstrap. Similarly, there may not be a need for the
fference between successive counted difference between successive counter
values to be a predictable. values to be predictable.
</t> </t>
<t>
<t>
A node that implements a per-context linear function may share the A node that implements a per-context linear function may share the
increment space among different contexts (please see the "Simple increment space among different contexts (please see the "Simple PRF-Based Al
Hash-Based Algorithm" in <xref target="I-D.irtf-pearg-numeric-ids-generation" gorithm" section in <xref target="RFC9415" format="default"/>).
/>).
Sharing the same increment space allows an attacker that can sample Sharing the same increment space allows an attacker that can sample
identifiers in other context to e.g. learn how many identifiers have identifiers in other context to, e.g., learn how many identifiers have
been generated between two sampled values. been generated between two sampled values.
</t> </t>
<t>Finally, some implementations have been found to employ flawed PRNGs (e
<t>Finally, some implementations have been found to employ flawed PRNGs (see e.g .g., see <xref target="Klein2007" format="default"/>).</t>
. <xref target="Klein2007"/>).</t> </section>
</section> <section anchor="reqs" numbered="true" toc="default">
<name>Requirements for Transient Numeric Identifiers</name>
<section title="Requirements for Transient Numeric Identifiers" anchor="reqs"> <t>Protocol specifications that employ transient numeric identifiers <bcp1
<t>Protocol specifications that employ transient numeric identifiers MUST explic 4>MUST</bcp14> explicitly specify the interoperability requirements for the afor
itly specify the interoperability requirements for the aforementioned transient ementioned transient numeric identifiers (e.g., required properties such as uniq
numeric identifiers (e.g., required properties such as uniqueness, along with th ueness, along with the failure severity if such requirements are not met).
e failure severity if such properties are not met).
</t> </t>
<t>A vulnerability assessment of the aforementioned transient numeric iden
<t>A vulnerability assessment of the aforementioned transient numeric identifier tifiers <bcp14>MUST</bcp14> be performed as part of the specification process.
s MUST be performed as part of the specification process. Such vulnerability assessment should cover, at least, spoofing, tampering, repud
Such vulnerability assessment should cover, at least, spoofing, tampering, repud iation, information disclosure, DoS, and
iation, information disclosure, denial of service, and
elevation of privilege. elevation of privilege.
<list style="hanging">
<t>
Note: Section 8 and Section 9 of <xref target="I-D.irtf-pearg-numeric-ids-genera
tion"/> provide a general vulnerability assessment of transient numeric identifi
ers, along with a vulnerability assessment of common algorithms for generating t
ransient numeric identifiers. Please see <xref target="Shostack2014"/> for furth
er guidance on threat modelling.
</t>
</list>
</t> </t>
<t>Protocol specifications SHOULD NOT employ predictable transient numeric ident <aside><t>NOTE: Sections <xref target="RFC9415" section="8" sectionFormat="bare"
ifiers, except when such predictability is the result of their interoperability format="default"/> and <xref target="RFC9415" section="9" sectionFormat="bare"
requirements. format="default"/> of <xref target="RFC9415" format="default"/> provide a genera
l vulnerability assessment of transient numeric identifiers, along with a vulner
ability assessment of common algorithms for generating transient numeric identif
iers. Please see <xref target="Shostack2014" format="default"/> for further guid
ance on threat modeling.
</t></aside>
<t>Protocol specifications <bcp14>SHOULD NOT</bcp14> employ predictable tr
ansient numeric identifiers, except when such predictability is the result of th
eir interoperability requirements.
</t> </t>
<t>Protocol specifications that employ transient numeric identifiers
<t>Protocol specifications that employ transient numeric identifiers <bcp14>SHOULD</bcp14> recommend an algorithm for generating the aforementione
SHOULD recommend an algorithm for generating the aforementioned d
transient numeric identifiers that mitigates the vulnerabilities transient numeric identifiers that mitigates the vulnerabilities
identified in the previous step, such as those discussed in identified in the previous step, such as those discussed in
<xref target="I-D.irtf-pearg-numeric-ids-generation"/>.</t> <xref target="RFC9415" format="default"/>.</t>
<t>
<t> As discussed in <xref target="intro" format="default"/>, use of cryptographic
As discussed in <xref target="intro"/>, use of cryptographic techniques for techniques for
confidentiality and authentication might not eliminate all the confidentiality and authentication might not eliminate all the
issues associated with predictable transient numeric identifiers. issues associated with predictable transient numeric identifiers.
Therefore, the advice from this section MUST still be applied Therefore, the advice from this section <bcp14>MUST</bcp14> still be applied
for cases where cryptographic techniques are employed for for cases where cryptographic techniques for
confidentiality or authentication of the associated confidentiality or authentication are employed.
transient numeric identifiers.
</t>
</section>
<section title="IANA Considerations" anchor="iana-considerations">
<t>There are no IANA registries within this document. </t>
</section>
<section title="Security Considerations">
<t>This entire document is about the security and privacy implications of transi
ent numeric identifiers, and formally updates <xref target="RFC3552"/> such that
the security and privacy implications of transient numeric identifiers are addr
essed when writing the "Security Considerations" section of future RFCs.
</t> </t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors would like to thank Bernard Aboba, Brian Carpenter, Roman Danyliw <t>This document has no IANA actions.</t>
, Theo de Raadt, Lars Eggert, Russ Housley, Benjamin Kaduk, Charlie Kaufman, Eri </section>
k Kline, Alvaro Retana, Joe Touch, Michael Tuexen, Robert Wilton, and Paul Woute <section numbered="true" toc="default">
rs, for providing valuable comments on earlier versions of this document.</t> <name>Security Considerations</name>
<t>This entire document is about the security and privacy implications of
<t>The authors would like to thank (in alphabetical order) Steven Bellovin, Jose transient numeric identifiers and formally updates <xref target="RFC3552" format
ph Lorenzo Hall, Gre Norcie, for providing valuable comments on <xref target="I- ="default"/> such that the security and privacy implications of transient numeri
D.gont-predictable-numeric-ids"/> , on which the present document is based.</t> c identifiers are addressed when writing the "Security Considerations" section o
f future RFCs.
<t>The authors would like to thank Diego Armando Maradona for his magic and insp </t>
iration.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.8174" ?>
<!-- Sec Cons -->
<?rfc include="reference.RFC.3552" ?>
<!--
<?rfc include="reference.RFC.4086" ?>
<!--
<?rfc include="reference.RFC.6151" ?>
<?rfc include="reference.RFC.7098" ?>
<displayreference target="I-D.gont-predictable-numeric-ids" to="PREDICTABLE-NUME
RIC-IDS"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.35
52.xml"/>
</references> </references>
<references>
<name>Informative References</name>
<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
217.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.62
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
739.xml"/>
<references title='Informative References'> <reference anchor="Sanfilippo1998a" target="https://seclists.org/bugtraq
/1998/Dec/48">
<!-- IPv6 IIDs --> <front>
<?rfc include="reference.RFC.7721" ?> <title>about the ip header id</title>
<?rfc include="reference.RFC.7217" ?> <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfi
<?rfc include="reference.RFC.7707" ?> lippo">
<organization/>
<!-- Frag IDs --> </author>
<?rfc include="reference.RFC.6274" ?> <date month="December" year="1998"/>
<?rfc include="reference.RFC.7739" ?> </front>
<reference anchor="Sanfilippo1998a" target="https://seclists.org/bugtraq/ <refcontent>message to the Bugtraq mailing list</refcontent>
1998/Dec/48"> </reference>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.07
<title>about the ip header id</title> 93.xml"/>
<author initials="S." surname="Sanfilippo" fullname="S. S <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
anfilippo"> 528.xml"/>
<organization></organization>
</author>
<date/>
</front>
<seriesInfo name="Post to Bugtraq mailing-list," value="Mon Dec 1
4 1998" />
</reference>
<!-- TCP sequence numbers -->
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.6528" ?> <!-- TCP SEQ randomization -->
<reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb /papers/ipext.pdf"> <reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb /papers/ipext.pdf">
<front> <front>
<title>Security Problems in the TCP/IP Protocol Suite</ti <title>Security Problems in the TCP/IP Protocol Suite</title>
tle> <author initials="S." surname="Bellovin" fullname="S. M. Bellovin">
<author initials="S." surname="Bellovin" fullname="Bellov <organization/>
in"> </author>
<organization></organization> <date month="April" year="1989"/>
</author> </front>
<date year="Computer Communications Review, vol. 19, no. <refcontent>Computer Communications Review, vol. 19, no. 2, pp. 32-48</
2, pp. 32-48, 1989"/> refcontent>
</front> </reference>
</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>
<!-- IPv6 -->
<?rfc include="reference.RFC.2460" ?>
<!-- Port randomization --> <reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/p
<?rfc include="reference.RFC.6056" ?> apers/117.pdf">
<reference anchor="Silbersack2005" target="http://www.silby.com/eurobsdco <front>
n05/eurobsdcon_silbersack.pdff"> <title>A Weakness in the 4.2BSD UNIX TCP/IP Software</title>
<front> <author initials="R." surname="Morris" fullname="Robert Morris">
<title>Improving TCP/IP security through randomization wi <organization/>
thout sacrificing interoperability</title> </author>
<author initials="M.J." surname="Silbersack" fullname="Mi <date year="1985" month="February"/>
chael James Silbersack"> </front>
<organization>The FreeBSD Project</organization> <refcontent>CSTR 117, AT&amp;T Bell Laboratories, Murray Hill, NJ</refc
</author> ontent>
<date year="2005"/> </reference>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.24
<seriesInfo name="EuroBSDCon 2005" value="Conference"/> 60.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
56.xml"/>
<?rfc include="reference.I-D.gont-predictable-numeric-ids" ?> <reference anchor="Silbersack2005" target="http://www.silby.com/eurobsdc
on05/eurobsdcon_silbersack.pdf">
<front>
<title>Improving TCP/IP security through randomization without sacri
ficing interoperability</title>
<author initials="M." surname="Silbersack" fullname="Michael James S
ilbersack">
<organization>The FreeBSD Project</organization>
</author>
<date year="2005" month="January"/>
</front>
<refcontent>EuroBSDCon 2005 Conference</refcontent>
</reference>
<!-- <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gont-pr
<?rfc include="reference.RFC.1321" ?> edictable-numeric-ids.xml"/>
<!-- Pervasive Monitoring --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="reference.RFC.7258" ?> 323.xml"/>
<reference anchor="TCPT-uptime" target="https://seclists.org/bugtraq/200
1/Mar/182">
<front>
<title>TCP Timestamping - Obtaining System Uptime Remotely</title>
<author initials="B." surname="McDanel" fullname="Bret McDanel">
<organization>Securiteam</organization>
</author>
<date month="March" year="2001"/>
</front>
<refcontent>message to the Bugtraq mailing list</refcontent>
</reference>
<!-- DNS --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72
<?rfc include="reference.RFC.1035" ?> 58.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.42
91.xml"/>
<!-- IPv6 addresses --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.07
<?rfc include="reference.RFC.4291" ?> 91.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.82
00.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
93.xml"/>
<!-- PNRG -->
<reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/papers/ attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerabili ty.pdf"> <reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/papers/ attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerabili ty.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>Trusteer</organization>
<organization>Trusteer</organization> </author>
</author> <date year="2007" month="October"/>
<date year="2007"/> </front>
</front> </reference>
</reference>
<reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/c
hristoph-schuba/schuba-DNS-msthesis.pdf">
<front>
<title>ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PR
OTOCOL</title>
<author initials="C." surname="Schuba" fullname="Christop
h Schuba">
<organization></organization>
</author>
<date year="1993"/>
</front>
</reference>
<reference anchor="Shostack2014"> <reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/
<front> papers/christoph-schuba/schuba-DNS-msthesis.pdf">
<title>Threat Modeling: Designing for Security</title> <front>
<author initials="A." surname="Shostack" fullname="Adam S <title>Addressing Weakness in the Domain Name System Protocol</title
hostack"> >
<organization></organization> <author initials="C." surname="Schuba" fullname="Christoph Schuba">
</author> <organization/>
<date year="2014"/> </author>
</front> <date year="1993" month="August"/>
<seriesInfo name="Wiley, " value="1st edition"/> </front>
</reference> </reference>
<?rfc include="reference.I-D.irtf-pearg-numeric-ids-history" ?> <reference anchor="Shostack2014">
<?rfc include="reference.I-D.irtf-pearg-numeric-ids-generation" ?> <front>
<title>Threat Modeling: Designing for Security</title>
<author initials="A." surname="Shostack" fullname="Adam Shostack">
<organization/>
</author>
<date year="2014" month="February"/>
</front>
<refcontent>Wiley, 1st edition</refcontent>
</reference>
<reference anchor="IANA-PROT" target="https://www.iana.org/protoc <reference anchor='RFC9414' target='https://www.rfc-editor.org/info/rfc9414'>
ols"> <front>
<front> <title>Unfortunate History of Transient Numeric Identifiers</title>
<title>Protocol Registries</title> <author initials='F' surname='Gont' fullname='Fernando Gont'>
<author initials="" surname="IANA" fullname="IANA"> <organization />
<organization></organization> </author>
</author> <author initials='I' surname='Arce' fullname='Ivan Arce'>
<organization />
</author>
<date year='2023' month='July'/>
</front>
<seriesInfo name="RFC" value="9414"/>
<seriesInfo name="DOI" value="10.17487/RFC9414"/>
</reference>
<date/> <reference anchor='RFC9415' target='https://www.rfc-editor.org/info/rfc941v'>
<front>
<title>On the Generation of Transient Numeric Identifiers</title>
<author initials='F' surname='Gont' fullname='Fernando Gont'>
<organization />
</author>
<author initials='I' surname='Arce' fullname='Ivan Arce'>
<organization />
</author>
<date year='2023' month='July'/>
</front>
<seriesInfo name="RFC" value="9415"/>
<seriesInfo name="DOI" value="10.17487/RFC9415"/>
</reference>
</front> <reference anchor="IANA-PROT" target="https://www.iana.org/protocols">
<!-- <front>
<seriesInfo name="" value="Federal Information Processing Standar <title>Protocol Registries</title>
ds Publication 180-4"/> <author>
<organization>IANA</organization>
</author>
</front>
</reference> </reference>
</references>
</references>
<section numbered="false" toc="default">
</references> <name>Acknowledgements</name>
<t>The authors would like to thank (in alphabetical order) <contact fullna
me="Bernard Aboba"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="
Roman Danyliw"/>, <contact fullname="Theo de Raadt"/>, <contact fullname="Lars E
ggert"/>, <contact fullname="Russ Housley"/>, <contact fullname="Benjamin Kaduk"
/>, <contact fullname="Charlie Kaufman"/>, <contact fullname="Erik Kline"/>, <co
ntact fullname="Alvaro Retana"/>, <contact fullname="Joe Touch"/>, <contact full
name="Michael Tüxen"/>, <contact fullname="Robert Wilton"/>, and <contact fullna
me="Paul Wouters"/> for providing valuable comments on draft versions of this do
cument.</t>
<t>The authors would like to thank (in alphabetical order) <contact fullna
me="Steven Bellovin"/>, <contact fullname="Joseph Lorenzo Hall"/>, and <contact
fullname="Gre Norcie"/> for providing valuable comments on <xref target="I-D.gon
t-predictable-numeric-ids" format="default"/>, on which the present document is
based.</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. 72 change blocks. 
468 lines changed or deleted 486 lines changed or added

This html diff was produced by rfcdiff 1.48.