rfc9414xml2.original.xml   rfc9414.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 symrefs="yes" ?>
<?rfc strict="no" ?>
<rfc category="info" docName="draft-irtf-pearg-numeric-ids-history-11" ipr="trus <!-- used by XSLT processors -->
t200902" submissionType="IRTF"> <!-- OPTIONS, known as processing instructions (PIs) go here. -->
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="
<title abbrev="Predictable Transient Numeric IDs">Unfortunate History of Transie info" consensus="true" docName="draft-irtf-pearg-numeric-ids-history-11" number=
nt Numeric Identifiers</title> "9414" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.16.0 -->
<front>
<title abbrev="Predictable Transient Numeric IDs">Unfortunate History of Tra
nsient Numeric Identifiers</title>
<seriesInfo name="RFC" value="9414"/>
<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> <extaddr>Segurola y Habana</extaddr>
<street>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> <extaddr>Segurola y Habana</extaddr>
<street>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>
<area>Internet</area> <keyword>fingerprinting</keyword>
<workgroup>Dynamic Host Configuration (dhc)</workgroup>
<!-- <area/> -->
<!-- <workgroup/> -->
<abstract> <abstract>
<t> <t>
This document analyzes the timeline of the specification and implementation of d This document analyzes the timeline of the specification and implementation of d
ifferent types of "transient numeric identifiers" used in IETF protocols, and ho ifferent types of "transient numeric identifiers" used in IETF protocols and how
w the security and privacy properties of such protocols have been affected as a the security and privacy properties of such protocols have been affected as a r
result of it. It provides empirical evidence that advice in this area is warrant esult of it. It provides empirical evidence that advice in this area is warrante
ed. This document is a product of the Privacy Enhancement and Assessment Researc d. This document is a product of the Privacy Enhancements and Assessments Resear
h Group (PEARG) in the IRTF. ch Group (PEARG) in the IRTF.
</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 targ
et="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
Networking protocols employ a variety of transient numeric identifiers for diffe rvice (DoS) or data injection to information leakages that could be exploited fo
rent protocol objects, such as IPv4 and IPv6 Fragment Identifiers <xref target=" r pervasive monitoring <xref target="RFC7258" format="default"/>. The root cause
RFC0791"/> <xref target="RFC8200"/>, IPv6 Interface Identifiers (IIDs) <xref tar of these issues has been, in many cases, the poor selection of transient numeri
get="RFC4291"/>, transport protocol ephemeral port numbers <xref target="RFC6056 c identifiers in such protocols, usually as a result of insufficient or misleadi
"/>, TCP Initial Sequence Numbers (ISNs) <xref target="RFC0793"/>, NTP Reference ng specifications. While it is generally trivial to identify an algorithm that c
IDs (REFIDs) <xref target="RFC5905"/>, and DNS Query IDs <xref target="RFC1035" an satisfy the interoperability requirements of a given transient numeric identi
/>. These identifiers typically have specific interoperability requirements (e.g fier, empirical evidence exists that doing so without negatively affecting the s
. uniqueness during a specified period of time), and associated failure severiti ecurity and/or privacy properties of the aforementioned protocols is prone to er
es when such requirements are not met <xref target="I-D.irtf-pearg-numeric-ids-g ror.</t>
eneration"/>. <t>For example, implementations have been subject to security and/or priva
</t> cy issues resulting from:</t>
<ul spacing="normal">
<t>For more than 30 years, a large number of implementations of the IETF protoco <li>predictable IPv4 or IPv6 Identification values (e.g., see <xref targ
ls have been subject to a variety of attacks, with effects ranging from Denial o et="Sanfilippo1998a" format="default"/>, <xref target="RFC6274" format="default"
f Service (DoS) or data injection, to information leakages that could be exploit />, and <xref target="RFC7739" format="default"/>),</li>
ed for pervasive monitoring <xref target="RFC7258"/>. The root cause of these is <li>predictable IPv6 IIDs (e.g., see <xref target="RFC7217" format="defa
sues has been, in many cases, poor selection of transient numeric identifiers, u ult"/>, <xref target="RFC7707" format="default"/>, and <xref target="RFC7721" fo
sually as a result of insufficient or misleading specifications.</t> rmat="default"/>),</li>
<li>predictable transport-protocol ephemeral port numbers (e.g., see <xr
<t>For example, implementations have been subject to security or privacy issues ef target="RFC6056" format="default"/> and <xref target="Silbersack2005" format=
resulting from: "default"/>),</li>
<li>predictable TCP Initial Sequence Numbers (ISNs) (e.g., see <xref tar
<list style="symbols"> get="Morris1985" format="default"/>, <xref target="Bellovin1989" format="default
<t>Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. <xref target="Sanfili "/>, and <xref target="RFC6528" format="default"/>),</li>
ppo1998a"/>, <xref target="RFC6274"/>, and <xref target="RFC7739"/>)</t> <li>predictable initial timestamps in TCP timestamps options (e.g., see
<t>Predictable IPv6 IIDs (see e.g. <xref target="RFC7721"/>, <xref target="RFC77 <xref target="TCPT-uptime" format="default"/> and <xref target="RFC7323" format=
07"/>, and <xref target="RFC7217"/>)</t> "default"/>), and</li>
<t>Predictable transport protocol ephemeral port numbers (see e.g. <xref target= <li>predictable DNS IDs (see, e.g., <xref target="Schuba1993" format="de
"RFC6056"/> and <xref target="Silbersack2005"/>)</t> fault"/> and <xref target="Klein2007" format="default"/>).</li>
<t>Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. <xref target="Morri </ul>
s1985"/>, <xref target="Bellovin1989"/>, and <xref target="RFC6528"/>)</t> <t>Recent history indicates that, when new protocols are standardized or n
<t>Predictable DNS Query IDs (see e.g. <xref target="Arce1997"/> and <xref targe ew protocol implementations are produced, the security and privacy properties of
t="Klein2007"/>)</t> the associated transient numeric identifiers tend to be overlooked, and inappro
</list> priate algorithms to generate such identifiers are either suggested in the speci
fications or selected by implementers. As a result, advice in this area is warra
These examples indicate that when new protocols are standardized or implemented, nted.
the security and privacy properties of the associated transient numeric identif
iers tend to be overlooked, and inappropriate algorithms to generate such identi
fiers (i.e. that negatively affect the security or privacy properties of the pro
tocol) are either suggested in the specification or selected by implementers.
</t>
<t>This document contains a non-exhaustive timeline of the specification and vul
nerability disclosures related to some sample transient numeric identifiers, inc
luding other work that has led to advances in this area. This analysis indicates
that:
<list style="symbols">
<t>Vulnerabilities associated with the inappropriate generation of transient num
eric identifiers have affected protocol implementations for an extremely long pe
riod of time.</t>
<t>Such vulnerabilities, even when addressed for a given protocol version, were
later reintroduced in new versions or new implementations of the same protocol.<
/t>
<t>Standardization efforts that discuss and provide advice in this area can have
a positive effect on IETF specifications and their corresponding implementation
s.</t>
</list>
</t>
<t>While it is generally possible to identify an algorithm that can satisfy the
interoperability requirements for a given transient numeric identifier, this doc
ument provides empirical evidence that doing so without negatively affecting the
security or privacy properties of the aforementioned protocols is non-trivial.
Other related documents (<xref target="I-D.irtf-pearg-numeric-ids-generation"/>
and <xref target="I-D.gont-numeric-ids-sec-considerations"/>) provide guidance i
n this area, as motivated by the present document.</t>
<t>This document represents the consensus of the Privacy Enhancement and Assessm
ent Research Group (PEARG).</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 ty
pe, in a given context. Transient numeric identifiers are usually defined as a s
eries of bits, and represented using integer values. These identifiers are typic
ally dynamically selected, as opposed to statically-assigned numeric identifiers
(see e.g. <xref target="IANA-PROT"/>). We note that different identifiers may h
ave additional requirements or properties depending on their specific use in a p
rotocol. We use the term "transient numeric identifier" (or simply "numeric iden
tifier" or "identifier" as short forms) as a generic term to refer to any data o
bject in a protocol specification that satisfies the identification property sta
ted above.
</t> </t>
<t>This document contains a non-exhaustive timeline of the specification a
</list> nd vulnerability disclosures related to some sample transient numeric identifier
s, including other work that has led to advances in this area. This analysis ind
icates that:
</t> </t>
<ul spacing="normal">
<li>vulnerabilities associated with the inappropriate generation of tran
sient numeric identifiers have affected protocol implementations for an extremel
y long period of time,</li>
<li>such vulnerabilities, even when addressed for a given protocol versi
on, were later reintroduced in new versions or new implementations of the same p
rotocol, and</li>
<li>standardization efforts that discuss and provide advice in this area
can have a positive effect on IETF specifications and their corresponding imple
mentations.</li>
</ul>
<t>While it is generally possible to identify an algorithm that can satisf
y the interoperability requirements for a given transient numeric identifier, th
is document provides empirical evidence that doing so without negatively affecti
ng the security and/or privacy properties of the corresponding protocols is nont
rivial. Other related documents (<xref target="RFC9415" format="default"/> and <
xref target="RFC9416" format="default"/>) provide guidance in this area, as moti
vated by the present document.</t>
<t>This document represents the consensus of the Privacy Enhancements and
Assessments Research Group (PEARG).</t>
</section>
<t> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<dl newline="true" spacing="normal">
<dt>Transient Numeric Identifier:</dt>
<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>
</dl>
<t>
The terms "constant IID", "stable IID", and "temporary IID" are to be The terms "constant IID", "stable IID", and "temporary IID" are to be
interpreted as defined in <xref target="RFC7721"/>. interpreted as defined in <xref target="RFC7721" format="default"/>.
</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">
<t>Throughout this document, we assume an attacker does not have physical or log
ical access to the system(s) being attacked, and cannot necessarily observe all
the packets being transferred between the sender and the receiver(s) of the
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>
</section>
<section title="Threat Model" anchor="threat-model">
<!--
<t>Throughout this document, we assume an attacker does not have physical or log
ical access to the system(s) being attacked, and cannot necessarily observe all
the packets being transferred between the sender and the receiver(s) of the
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>Throughout this document, we do not consider on-path attacks. That is, we ass
ume the attacker does not have physical or logical access to the system(s) being
attacked, and that the attacker can only observe traffic explicitly directed to
the attacker. Similarly, an attacker cannot observe traffic transferred between
a sender and the receiver(s) of a target protocol, but may be able to interact
with any of these entities, including by e.g. sending any traffic to them to sam
ple transient numeric identifiers employed by the target systems when communicat
ing with the attacker.
</t>
<t>For example, when analyzing vulnerabilities associated with TCP Initial Seque
nce Numbers (ISNs), we consider the attacker is unable to capture network traffi
c corresponding to a TCP connection between two other hosts. However, we conside
r the attacker is able to communicate with any of these hosts (e.g., establish a
TCP connection with any of them), to e.g. sample the TCP ISNs employed by these
systems when communicating with the attacker.</t>
<t>Similarly, when considering host-tracking attacks based on IPv6 interface ide
ntifiers, we consider an attacker may learn the IPv6 address employed by a victi
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>
</section>
<section title="Issues with the Specification of Transient Numeric Identifiers"
anchor="issues">
<t>While assessing IETF protocol specifications regarding the use of transient n
umeric identifiers, we have found that most of the issues discussed in this docu
ment arise as a result of one of the following conditions:
<list style="symbols">
<t>Protocol specifications that under-specify the requirements for their transie
nt numeric identifiers</t>
<t>Protocol specifications that over-specify their transient numeric identifiers
</t>
<t>Protocol implementations that simply fail to comply with the specified requir
ements</t>
</list>
</t>
<t>A number of IETF protocol specifications have simply overlooked the security
and privacy implications of transient numeric identifiers. Examples of them are
the specification of TCP ephemeral ports in <xref target="RFC0793"/>, the specif
ication of TCP sequence numbers in <xref target="RFC0793"/>, or the specificatio
n of the DNS TxID in <xref target="RFC1035"/>.</t>
<t>On the other hand, there are a number of IETF protocol specifications that ov
er-specify some of their associated transient numeric identifiers. For example,
<xref target="RFC4291"/> essentially overloads the semantics of IPv6 Interface I
dentifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs, when the i
nteroperability requirement of uniqueness could be achieved in other ways that d
o not result in negative security and privacy implications <xref target="RFC7721
"/>. Similarly, <xref target="RFC2460"/> suggested the use of a global counter f
or the generation of Fragment Identification values, when the interoperability p
roperties of uniqueness per {Src IP, Dst IP} could be achieved with other algori
thms that do not result in negative security and privacy implications <xref targ
et="RFC7739"/>.</t>
<t>Finally, there are implementations that simply fail to comply with the corres
ponding IETF protocol specifications or recommendations. For example, some popul
ar operating systems (notably Microsoft Windows) still fail to implement transpo
rt protocol ephemeral port randomization, as recommended in <xref target="RFC605
6"/>.</t>
<t>The following subsections document the timelines for a number of sample trans
ient numeric identifiers, that illustrate how the problem discussed in this docu
ment has affected protocols from different layers over time. These sample transi
ent numeric identifiers have different interoperability requirements and failure
severities (see Section 6 of <xref target="I-D.irtf-pearg-numeric-ids-generatio
n"/>), and thus are considered to be representative of the problem being analyze
d in this document.</t>
<section title="IPv4/IPv6 Identification" anchor="ipid">
<t>This section presents the timeline of the Identification field employed by IP
v4 (in the base header) and IPv6 (in Fragment Headers). The reason for presentin
g both cases in the same section is to make it evident that while the Identifica
tion value serves the same purpose in both IPv4 and IPv6, the work and research
done for the IPv4 case did not affect IPv6 specifications or implementations.</t
>
<t>The IPv4 Identification is specified in <xref target="RFC0791"/>, which speci
fies the interoperability requirements for the Identification field: the sender
must choose the Identification field to be unique for a given source address, d
estination address, and protocol, for the time the datagram (or any fragment of
it) could be alive in the internet. It suggests that a node may keep "a table of
Identifiers, one entry for each destination it has communicated with in the las
t maximum packet lifetime for the internet", and suggests that "since the Identi
fier field allows 65,536 different values, hosts may be able to simply use uniqu
e identifiers independent of destination". The above has been interpreted numero
us times as a suggestion to employ per-destination or global counters for the ge
neration of Identification values. While <xref target="RFC0791"/> does not sugge
st any flawed algorithm for the generation of Identification values, the specifi
cation omits a discussion of the security and privacy implications of predictabl
e Identification values. This has resulted in many IPv4 implementations generati
ng predictable fragment Identification values by means of a global counter, at l
east at some point in time.
</t>
<t>
The IPv6 Identification was originally specified in <xref target="RFC1883"/>. It
serves the same purpose as its IPv4 counterpart, with the only difference resid
ing in the length of the corresponding field, and that while the IPv4 Identifica
tion field is part of the base IPv4 header, in the IPv6 case it is part of the F
ragment header (which may or may not be present in an IPv6 packet). <xref target
="RFC1883"/> states, in Section 4.5, that the Identification must be different t
han that of any other fragmented packet sent recently (within the maximum likely
lifetime of a packet) with the same Source Address and Destination Address. Sub
sequently, it notes that this requirement can be met by means of a wrap-around 3
2-bit counter that is incremented each time a packet must be fragmented, and tha
t it is an implementation choice whether to use a global or a per-destination co
unter. Thus, the implementation of the IPv6 Identification is similar to that of
the IPv4 case, with the only difference that in the IPv6 case the suggestions t
o use simple counters is more explicit. <xref target="RFC2460"/> was the first r
evision of the core IPv6 specification, and maintained the same text for the spe
cification of the IPv6 Identification field. <xref target="RFC8200"/>, the secon
d revision of the core IPv6 specification, removes the suggestion from <xref tar
get="RFC2460"/> to use a counter for the generation of IPv6 Identification value
s, and points to <xref target="RFC7739"/> for sample algorithms for their genera
tion.
</t>
<t>
<list style="hanging">
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0791"/> specifies the interoperability
requirements for IPv4 Identification value, but does not perform a vulnerabilit
y assessment of this transient numeric identifier.
</t>
<t hangText="December 1995:">
<vspace blankLines="0" /><xref target="RFC1883"/>, the first specification of th
e IPv6 protocol, is published. It suggests that a counter be used to generate th
e IPv6 Identification value, and notes that it is an implementation choice wheth
er to maintain a single counter for the node or multiple counters, e.g., one for
each of the node's possible source addresses, or one for each active (source ad
dress, destination address) combination.
</t>
<t hangText="December 1998:">
<vspace blankLines="0" /><xref target="Sanfilippo1998a"/> finds that predictable
IPv4 Identification values (generated by most popular implementations) can be l
everaged to count the number of packets sent by a target node. <xref target="San
filippo1998b"/> explains how to leverage the same vulnerability to implement a p
ort-scanning technique known as &quot;dumb/idle scan&quot;. A tool that implemen
ts this attack is publicly released.
</t>
<t hangText="December 1998:">
<vspace blankLines="0" /><xref target="RFC2460"/>, a revision of the IPv6 specif
ication, is published, obsoleting <xref target="RFC1883"/>. It maintains the sam
e specification of the IPv6 Identification field as its predecessor (<xref targe
t="RFC1883"/>).
</t>
<t hangText="December 1998:">
<vspace blankLines="0" />OpenBSD implements randomization of the IPv4 Identifica
tion field <xref target="OpenBSD-IPv4-ID"/>. <!--This feature eventually shipped
with OpenBSD 2.5.-->
</t>
<t hangText="November 1999:">
<vspace blankLines="0" /><xref target="Sanfilippo1999"/> discusses how to levera
ge predictable IPv4 Identification to uncover the rules of a number of firewalls
.
</t>
<t hangText="September 2002:">
<vspace blankLines="0" /><xref target="Fyodor2002"/> documents the implementatio
n of the "idle/dumb scan" technique in the popular nmap tool.
</t>
<t hangText="November 2002:">
<vspace blankLines="0" /><xref target="Bellovin2002"/> explains how the IPv4 Ide
ntification field can be exploited to count the number of systems behind a NAT.
</t>
<t hangText="October 2003:">
<vspace blankLines="0" />OpenBSD implements randomization of the IPv6 Identifica
tion field <xref target="OpenBSD-IPv6-ID"/>.<!-- This feature eventually shipped
with OpenBSD 3.4.-->
</t>
<t hangText="December 2003:">
<vspace blankLines="0" /><xref target="Zalewski2003"/> explains a technique to p
erform TCP data injection attacks based on predictable IPv4 identification value
s, which requires less effort than TCP injection attacks performed with bare TCP
packets.
</t>
<t hangText="November 2005:">
<vspace blankLines="0" /><xref target="Silbersack2005"/> discusses shortcomings
in a number of techniques to mitigate predictable IPv4 Identification values.
</t>
<t hangText="October 2007:">
<vspace blankLines="0" /><xref target="Klein2007"/> describes a weakness in the
pseudo random number generator (PRNG) in use for the generation of the IP Identi
fication by a number of operating systems.
</t>
<t hangText="June 2011:">
<vspace blankLines="0" /><xref target="Gont2011"/> describes how to perform dumb
/idle scan attacks in IPv6.
</t>
<t hangText="November 2011:">
<vspace blankLines="0" />Linux mitigates predictable IPv6 Identification values
<xref target="RedHat2011"/> <xref target="SUSE2011"/> <xref target="Ubuntu2011"/
>.
</t>
<t hangText="December 2011:">
<vspace blankLines="0" /><xref target="draft-gont-6man-predictable-fragment-id-0
0"/> describes the security implications of predictable IPv6 Identification valu
es, and possible mitigations. This document has the Intended Status of &quot;Sta
ndards Track&quot;, with the intention to formally update <xref target="RFC2460"
/>, to introduce security and privacy requirements on the generation of IPv6 Ide
ntification values.
</t>
<t hangText="May 2012:">
<vspace blankLines="0" /><xref target="Gont2012"/> notes that some major IPv6 im
plementations still employ predictable IPv6 Identification values.
</t>
<!-- [fgont] Historia de RFC7739 -->
<t hangText="March 2013:">
<vspace blankLines="0" />The 6man WG adopts <xref target="I-D.gont-6man-predicta
ble-fragment-id"/>, but changes the track to "BCP" (while still formally updatin
g <xref target="RFC2460"/>), publishing the resulting document as <xref target="
draft-ietf-6man-predictable-fragment-id-00"/>.
</t>
<t hangText="June 2013:">
<vspace blankLines="0" />A patch to incorporate support for IPv6-based idle/dumb
scans in nmap is submitted <xref target="Morbitzer2013"/>.
</t>
<t hangText="December 2014:">
<vspace blankLines="0" />The 6man WG changes the Intended Status of <xref target
="draft-ietf-6man-predictable-fragment-id-01"/> to "Informational" and publishes
it as <xref target="draft-ietf-6man-predictable-fragment-id-02"/>. As a result,
it no longer formally updates <xref target="RFC2460"/>, and security and privac
y requirements on the generation of IPv6 Identification values are eliminated.
</t>
<t hangText="June 2015:">
<vspace blankLines="0" /><xref target="draft-ietf-6man-predictable-fragment-id-0
8"/> notes that some popular host and router implementations still employ predic
table IPv6 Identification values.
</t>
<t hangText="February 2016:">
<vspace blankLines="0" /><xref target="RFC7739"/> (based on <xref target="I-D.ie
tf-6man-predictable-fragment-id"/>) analyzes the security and privacy implicatio
ns of predictable IPv6 Identification values, and provides guidance for selectin
g an algorithm to generate such values. However, being published with the Intend
ed Status of &quot;Informational&quot;, it does not formally update <xref target
="RFC2460"/>, and does not introduce security and privacy requirements on the ge
neration of IPv6 Identification values. <!--Note: The oiginal individual submiss
ion IP, revision of <xref target="RFC2460"/> removes the suggestion from RFC2460
to employ a global counter for the generation of IPv6 Identification values, bu
t does specify any security and privacy requirements for the IPv6 Identification
value.-->
</t>
<t hangText="June 2016:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc2460bis"/>, revision of
<xref target="RFC2460"/>, removes the suggestion from RFC2460 to use a counter f
or the generation of IPv6 Identification values, but does not perform a vulnerab
ility assessment of the generation of IPv6 Identification values, and does not i
ntroduce security and privacy requirements on the generation of IPv6 Identificat
ion values.
</t>
<t hangText="July 2017:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc2460bis"/> is finally pu
blished as <xref target="RFC8200"/>, obsoleting <xref target="RFC2460"/>, and po
inting to <xref target="RFC7739"/> for sample algorithms for the generation of I
Pv6 Fragment Identification values. However, it does not introduce security and
privacy requirements on the generation of IPv6 Identification values.
</t>
<t hangText="June 2019:">
<vspace blankLines="0" /><xref target="IPID-DEV"/> notes that the IPv6 ID genera
tors of two popular operating systems are flawed.
</t>
</list>
</t>
</section>
<section title="TCP Initial Sequence Numbers (ISNs)" anchor="tcp-isns">
<t>
<xref target="RFC0793"/> suggests that the choice of the ISN of a connection is
not arbitrary, but aims to reduce the chances of a stale segment from being acce
pted by a new incarnation of a previous connection. <xref target="RFC0793"/> sug
gests the use of a global 32-bit ISN generator that is incremented by 1 roughly
every 4 microseconds. However, as a matter of fact, protection against stale seg
ments from a previous incarnation of the connection is enforced by preventing th
e creation of a new incarnation of a previous connection before 2*MSL have passe
d since a segment corresponding to the old incarnation was last seen (where "MSL
" is the "Maximum Segment Lifetime" <xref target="RFC0793"/>). This is accomplis
hed by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of <xr
ef target="RFC1323"/>). Based on the assumption that ISNs are monotonically incr
easing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an
incoming SYN segment to perform "heuristics" that enable the creation of a new i
ncarnation of a connection while the previous incarnation is still in the TIME-W
AIT state (see p. 945 of <xref target="Wright1994"/>). This avoids an interopera
bility problem that may arise when a node establishes connections to a specific
TCP end-point at a high rate <xref target="Silbersack2005"/>.</t>
<t>The interoperability requirements for TCP ISNs are probably not as clearly sp
elled out as one would expect. Furthermore, the suggestion of employing a global
counter in <xref target="RFC0793"/> negatively affects the security and privacy
properties of the protocol.</t>
<t>
<list style="hanging">
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0793"/>, suggests the use of a global
32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However,
such an ISN generator makes it trivial to predict the ISN that a TCP instance w
ill use for new connections, thus allowing a variety of attacks against TCP.
</t>
<!--
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0793"/>, suggests the use of a global
32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However,
such an ISN generator makes it trivial to predict the ISN that a TCP will use f
or new connections, thus allowing a variety of attacks against TCP.
</t>
<t hangText="February 1985:">
<vspace blankLines="0" /><xref target="Morris1985"/> was the first to describe h
ow to exploit predictable TCP ISNs for forging TCP connections that could then b
e leveraged for trust relationship exploitation.
</t>
<t hangText="April 1989:">
<vspace blankLines="0" /><xref target="Bellovin1989"/> discussed the security co
nsiderations for predictable ISNs (along with a range of other protocol-based vu
lnerabilities).
</t>
<t hangText="February 1995:">
<vspace blankLines="0" /><xref target="Shimomura1995"/> reported a real-world ex
ploitation of the attack described in <xref target="Morris1985"/> ten years befo
re (in 1985).
</t>
<t hangText="May 1996:">
<vspace blankLines="0" /><xref target="RFC1948"/> was the first IETF effort, aut
hored by Steven Bellovin, to address predictable TCP ISNs. However, <xref target
="RFC1948"/> does not formally update <xref target="RFC0793"/>. The same concept
specified in this document for TCP ISNs was later proposed for TCP ephemeral po
rts <xref target="RFC6056"/>, TCP Timestamps, and eventually even IPv6 Interface
Identifiers <xref target="RFC7217"/>.
</t>
<t hangText="July 1996:">
<vspace blankLines="0" />OpenBSD implements TCP ISN randomization based on rando
m increments (please see Appendix A.2 of <xref target="I-D.irtf-pearg-numeric-id
s-generation"/>) <xref target="OpenBSD-TCP-ISN-I"/>. <!-- This feature eventuall
y shipped with OpenBSD 2.0. -->
</t>
<t hangText="December 2000:">
<vspace blankLines="0" />OpenBSD implements TCP ISN randomization using simple r
andomization (please see Section 7.1 of <xref target="I-D.irtf-pearg-numeric-ids
-generation"/>) <xref target="OpenBSD-TCP-ISN-R"/>. <!-- This feature eventuall
y shipped with OpenBSD 2.9. -->
</t>
<t hangText="March 2001:">
<vspace blankLines="0" /><xref target="Zalewski2001"/> provides a detailed analy
sis of statistical weaknesses in some ISN generators, and includes a survey of t
he algorithms in use by popular TCP implementations.
</t>
<t hangText="May 2001:">
<vspace blankLines="0" />Vulnerability advisories <xref target="CERT2001"/> <xre
f target="USCERT2001"/> were released regarding statistical weaknesses in some I
SN generators, affecting popular TCP implementations.
</t>
<t hangText="March 2002:">
<vspace blankLines="0" /><xref target="Zalewski2002"/> updates and complements <
xref target="Zalewski2001"/>. It concludes that "while some vendors [...] reacte
d promptly and tested their solutions properly, many still either ignored the is
sue and never evaluated their implementations, or implemented a flawed solution
that apparently was not tested using a known approach" <xref target="Zalewski200
2"/>.
</t>
<t hangText="June 2007:">
<vspace blankLines="0" />OpenBSD implements TCP ISN randomization based on the a
lgorithm specified in <xref target="RFC1948"/> (currently obsoleted and replaced
by <xref target="RFC6528"/>) for the TCP endpoint that performs the active open
, while keeping the simple randomization scheme for the endpoint performing the
passive open <xref target="OpenBSD-TCP-ISN-H"/>. This provides monotonically-inc
reasing ISNs for the client side (allowing the BSD heuristics to work as expecte
d), while avoiding any patterns in the ISN generation for the server side.<!-- T
his feature eventually shipped with OpenBSD 4.2. -->
</t>
<t hangText="February 2012:">
<vspace blankLines="0" /><xref target="RFC6528"/>, published 27 years after Morr
is' original work <xref target="Morris1985"/>, formally updates <xref target="RF
C0793"/> to mitigate predictable TCP ISNs.
</t>
<t hangText="August 2014:">
<vspace blankLines="0" /><xref target="I-D.eddy-rfc793bis-04"/>, the upcoming re
vision of the core TCP protocol specification, incorporates the algorithm specif
ied in <xref target="RFC6528"/> as the recommended ("SHOULD") algorithm for TCP
ISN generation.
</t>
</list>
</t>
</section>
<section title="IPv6 Interface Identifiers (IIDs)" anchor="ipv6-iids">
<t>IPv6 Interface Identifiers can be generated as a result of different mechanis
ms, including SLAAC <xref target="RFC4862"/>, DHCPv6 <xref target="RFC8415"/>, a
nd manual configuration. This section focuses on Interface Identifiers resulting
from SLAAC.</t>
<t>The Interface Identifier of stable (traditional) IPv6 addresses resulting fro
m SLAAC have traditionally resulted in the underlying link-layer address being e
mbedded in the IID.<!-- IPv6 addresses resulting from SLAAC are currently requir
ed to employ Modified EUI-64 format identifiers, which essentially embed the und
erlying link-layer address of the corresponding network interface. --> At the t
ime, employing the underlying link-layer address for the IID was seen as a conve
nient way to obtain a unique address. However, recent awareness about the securi
ty and privacy properties of this approach <xref target="RFC7707"/> <xref target
="RFC7721"/> has led to the replacement of this flawed scheme with an alternativ
e one <xref target="RFC7217"/> <xref target="RFC8064"/> that does not negatively
affect the security and privacy properties of the protocol.
</t>
<t>
<list style="hanging">
<t hangText="January 1997:">
<vspace blankLines="0" /><xref target="RFC2073"/> specifies the syntax of IPv6 g
lobal addresses (referred to as "An IPv6 Provider-Based Unicast Address Format"
at the time), consistent with the IPv6 addressing architecture specified in <xre
f target="RFC1884"/>. Hosts are recommended to "generate addresses using link-sp
ecific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses".
</t>
<t hangText="July 1998:">
<vspace blankLines="0" /><xref target="RFC2374"/> specifies "An IPv6 Aggregatabl
e Global Unicast Address Format" (obsoleting <xref target="RFC2373"/>) changing
the size of the IID to 64 bits, and specifies that IIDs must be constructed in I
EEE EUI-64 format. How such identifiers are constructed becomes specified in the
corresponding "IPv6 over &lt;link&gt;" specifications, such as "IPv6 over Ether
net".
</t>
<t hangText="January 2001:">
<vspace blankLines="0" /><xref target="RFC3041"/> recognizes the problem of netw
ork activity correlation, and specifies temporary addresses. Temporary addresses
are to be used along with stable addresses.
</t>
<t hangText="August 2003:">
<vspace blankLines="0" /><xref target="RFC3587"/> obsoletes <xref target="RFC237
4"/>, making the TLA/NLA structure historic. The syntax and recommendations for
the traditional stable IIDs remain unchanged, though.
</t>
<t hangText="February 2006:">
<vspace blankLines="0" /><xref target="RFC4291"/> is published as the latest "IP
Version 6 Addressing Architecture", requiring the IIDs of the traditional (stab
le) IPv6 addresses resulting from SLAAC to employ the Modified EUI-64 format. Th
e details of constructing such interface identifiers are defined in the correspo
nding "IPv6 over &lt;link&gt;" specifications.
</t>
<t hangText="March 2008:">
<vspace blankLines="0" /><xref target="RFC5157"/> provides hints regarding how p
atterns in IPv6 addresses could be leveraged for the purpose of address scanning
.
</t>
<t hangText="December 2011:">
<vspace blankLines="0" /><xref target="draft-gont-6man-stable-privacy-addresses-
00"/> notes that the traditional scheme for generating stable addresses allows f
or address scanning, and also does not prevent active node tracking. It also spe
cifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 f
ormat identifiers.
</t>
<t hangText="November 2012:">
<vspace blankLines="0" />The 6man WG adopts <xref target="I-D.gont-6man-stable-p
rivacy-addresses"/> as a working group item (as <xref target="draft-ietf-6man-st
able-privacy-addresses-00"/>). However, the document no longer formally updates
<xref target="RFC4291"/>, and therefore the specified algorithm no longer formal
ly replaces the Modified EUI-64 format identifiers.
</t>
<t hangText="February 2013:">
<vspace blankLines="0" />An address-scanning tool (scan6 of <xref target="IPv6-T
oolkit"/>) that leverages IPv6 address patterns is released <xref target="Gont20
13"/>.
</t>
<t hangText="July 2013:">
<vspace blankLines="0" /><xref target="I-D.cooper-6man-ipv6-address-generation-p
rivacy"/> elaborates on the security and privacy properties of all known algorit
hms for generating IPv6 IIDs.
</t>
<t hangText="January 2014:">
<vspace blankLines="0" />The 6man WG publishes <xref target="draft-ietf-6man-def
ault-iids-00"/> ("Recommendation on Stable IPv6 Interface Identifiers"), recomme
nding <xref target="I-D.ietf-6man-stable-privacy-addresses"/> for the generation
of stable addresses.
</t>
<t hangText="April 2014:">
<vspace blankLines="0" /><xref target="RFC7217"/> (formerly <xref target="I-D.ie
tf-6man-stable-privacy-addresses"/>) is published, specifying "A Method for Gene
rating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Aut
oconfiguration (SLAAC)" as an alternative to (but *not* replacement of) Modified
EUI-64 format IIDs.
</t>
<t hangText="March 2016:">
<vspace blankLines="0" /><xref target="RFC7707"/> (formerly <xref target="I-D.go
nt-opsec-ipv6-host-scanning"/>, and later <xref target="I-D.ietf-opsec-ipv6-host
-scanning"/>), about "Network Reconnaissance in IPv6 Networks", is published.
</t>
<t hangText="March 2016:">
<vspace blankLines="0" /><xref target="RFC7721"/> (formerly <xref target="I-D.co
oper-6man-ipv6-address-generation-privacy"/> and later <xref target="I-D.ietf-6m
an-ipv6-address-generation-privacy"/>), about "Security and Privacy Consideratio
ns for IPv6 Address Generation Mechanisms", is published.
</t>
<t hangText="May 2016:">
<vspace blankLines="0" /><xref target="draft-gont-6man-non-stable-iids-00"/> is
published, with the goal of specifying requirements for non-stable addresses, an
d updating <xref target="RFC4941"/> such that use of only temporary addresses is
allowed.
</t>
<t hangText="May 2016:">
<vspace blankLines="0" /><xref target="draft-gont-6man-address-usage-recommendat
ions-00"/> is published, providing an analysis of how different aspects on an ad
dress (from stability to usage mode) affect their corresponding security and pri
vacy properties, and meaning to eventually provide advice in this area.
</t>
<t hangText="February 2017:">
<vspace blankLines="0" />The 6man WG publishes <xref target="RFC8064"/> ("Recomm
endation on Stable IPv6 Interface Identifiers") (formerly <xref target="I-D.ietf
-6man-default-iids"/>), with requirements for stable addresses and a recommendat
ion to employ <xref target="RFC7217"/> for the generation of stable addresses. I
t formally updates a large number of RFCs.
</t>
<t hangText="March 2018:">
<vspace blankLines="0" /><xref target="draft-fgont-6man-rfc4941bis-00"/> is publ
ished (as suggested by the 6man WG), to address flaws in <xref target="RFC4941"/
> by revising it (as an alternative to the <xref target="draft-gont-6man-non-sta
ble-iids-00"/> effort, published in March 2016).
</t>
<t hangText="July 2018:">
<vspace blankLines="0" /><xref target="draft-fgont-6man-rfc4941bis-00"/> is adop
ted (as <xref target="draft-ietf-6man-rfc4941bis-00"/>) as a WG item of the 6man
WG.
</t>
<t hangText="December 2020:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc4941bis"/> is approved b
y the IESG for publication as an RFC.
</t>
<t hangText="February 2021:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc4941bis"/> is finally pu
blished as <xref target="RFC8981"/>.
</t>
</list>
</t>
</section>
<section title="NTP Reference IDs (REFIDs)" anchor="ntp-refid">
<t>The NTP <xref target="RFC5905"/> Reference ID is a 32-bit code identifying th
e particular server or reference clock. Above stratum 1 (secondary servers and c
lients), this value can be employed to avoid degree-one timing loops; that is, s
cenarios where two NTP peers are (mutually) the time source of each other. If us
ing the IPv4 address family, the identifier is the four-octet IPv4 address. If
using the IPv6 address family, it is the first four octets of the MD5 hash of th
e IPv6 address.</t>
<t>
<list style="hanging">
<t hangText="June 2010:">
<vspace blankLines="0" /><xref target="RFC5905"/>, "Network Time Protocol Versio
n 4: Protocol and Algorithms Specification" is published. It specifies that for
NTP peers with stratum higher than 1 the REFID embeds the IPv4 Address of the ti
me source or an MD5 hash of the IPv6 address of the time source.
</t>
<t hangText="July 2016:">
<vspace blankLines="0" /><xref target="draft-stenn-ntp-not-you-refid-00"/> is pu
blished, describing the information leakage produced via the NTP REFID. It propo
ses that NTP returns a special REFID when a packet employs an IP Source Address
that is not believed to be a current NTP peer, but otherwise generates and retur
ns the traditional REFID. It is subsequently adopted by the NTP WG as <xref targ
et="I-D.ietf-ntp-refid-updates"/>.
</t>
<t hangText="April 2019:">
<vspace blankLines="0" /><xref target="Gont-NTP"/> notes that the proposed fix s
pecified in <xref target="draft-ietf-ntp-refid-updates-00"/> is, at the very lea
st, sub-optimal. As a result of lack of WG support, the effort is eventually aba
ndoned.
</t>
</list>
</t>
</section>
<section title="Transport Protocol Ephemeral Port Numbers" anchor="port-numbers"
>
<t>Most (if not all) transport protocols employ "port numbers" to demultiplex pa
ckets to the corresponding transport protocol instances.</t>
<!-- [fgont] esto hay que expandirlo, como en los otros casos -->
<t>
<list style="hanging">
<t hangText="August 1980:">
<vspace blankLines="0" /><xref target="RFC0768"/> notes that the UDP source port
is optional and identifies the port of the sending process. It does not specify
interoperability requirements for source port selection, nor does it suggest po
ssible ways to select port numbers. Most popular implementations end up selectin
g source ports from a system-wide global counter.</t>
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0793"/> (the TCP specification) essent
ially describes the use of port numbers, and specifies that port numbers should
result in a unique socket pair (local address, local port, remote address, remot
e port). How ephemeral ports (i.e. port numbers for "active opens") are selected
, and the port range from which they are selected, are left unspecified.
</t>
<t hangText="July 1996:">
<vspace blankLines="0" />OpenBSD implements ephemeral port randomization <xref t
arget="OpenBSD-PR"/>.<!-- This feature eventually shipped with OpenBSD 2.0.-->
</t>
<t hangText="July 2008:">
<vspace blankLines="0" />The CERT Coordination Centre published details of what
became known as the &quot;Kaminsky Attack&quot; <xref target="VU-800113"/> <xref
target="Kaminsky2008"/> on the DNS. The attack exploited the lack of source por
t randomization in many major DNS implementations to perform cache poisoning in
an effective and practical manner.
</t>
<t hangText="January 2009:">
<vspace blankLines="0" /><xref target="RFC5452"/> mandates the use of port rando
mization for DNS resolvers, and mandates that implementations must randomize por
ts from the range (53 or 1024, and above) or the largest possible port range. It
does not recommend possible algorithms for port randomization, although the doc
ument specifically targets DNS resolvers, for which a simple port randomization
suffices (e.g. Algorithm 1 of <xref target="RFC6056"/>). This document led to th
e implementation of port randomization in the DNS resolver themselves, rather th
an in the underlying transport-protocols.
</t> </t>
</section>
<t hangText="January 2011:"> <section anchor="threat-model" numbered="true" toc="default">
<vspace blankLines="0" /><xref target="RFC6056"/> notes that many TCP and UDP im <name>Threat Model</name>
plementations result in predictable port numbers, and also notes that many imple
mentations select port numbers from a small portion of the whole port number spa
ce. It recommends the implementation and use of ephemeral port randomization, pr
oposes a number of possible algorithms for port randomization, and also recommen
ds to randomize port numbers over the range 1024-65535.
</t>
<t hangText="March 2016:"> <t>Throughout this document, we do not consider on-path attacks. That is, we ass
<vspace blankLines="0" /><xref target="NIST-NTP"/> reports a non-normal distribu ume the attacker does not have physical or logical access to the system(s) being
tion of the ephemeral port numbers employed by the NTP clients of an Internet Ti attacked and that the attacker can only observe traffic explicitly directed to
me Service. the attacker. Similarly, an attacker cannot observe traffic transferred between
the sender and the receiver(s) of a target protocol but may be able to interact
with any of these entities, including by, e.g., sending any traffic to them to s
ample transient numeric identifiers employed by the target hosts when communicat
ing with the attacker.
</t> </t>
<t hangText="April 2019:"> <t>For example, when analyzing vulnerabilities associated with TCP Initial
<vspace blankLines="0" /><xref target="I-D.gont-ntp-port-randomization"/> notes Sequence Numbers (ISNs), we consider the attacker is unable to capture network
that some NTP implementations employ the NTP service port (123) as the local por traffic corresponding to a TCP connection between two other hosts. However, we c
t for non-symmetric modes, and aims to update the NTP specification to recommend onsider the attacker is able to communicate with any of these hosts (e.g., estab
port randomization in such cases, in line with <xref target="RFC6056"/>. The pr lish a TCP connection with any of them) to, e.g., sample the TCP ISNs employed b
oposal experiences some push-back in the relevant working group (NTP WG) <xref t y these hosts when communicating with the attacker.</t>
arget="NTP-PORTR"/>, but is finally adopted as a working group item as <xref tar <t>Similarly, when considering host-tracking attacks based on IPv6 Interfa
get="I-D.ietf-ntp-port-randomization"/>. 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
t communicating with an attacker-operated server. Subsequently, an attacker may
perform host-tracking by probing a set of target addresses composed by a set of
target prefixes and the IPv6 Interface Identifier originally learned by the atta
cker.
Alternatively, an attacker may perform host-tracking if, e.g., the victim
host communicates with an attacker-operated server as it moves from one location
to another, thereby exposing its configured addresses. We note that none of the
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:
<t hangText="August 2021:">
<vspace blankLines="0" /><xref target="I-D.ietf-ntp-port-randomization"/> is fin
ally published as <xref target="RFC9109"/>.
</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>
</section> <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
<section title="DNS Query ID" anchor="dns-query-id"> " format="default"/>.</t></aside>
<t>The DNS Query ID <xref target="RFC1035"/> can be employed to match DNS replie
s to outstanding DNS queries.
<list style="hanging">
<t hangText="November 1987:">
<vspace blankLines="0" /><xref target="RFC1035"/> specifies that the ID is a 16
bit identifier assigned by the program that
generates any kind of query, and that this identifier is copied in the correspon
ding reply and can be used by the requester to match up replies to outstanding q
ueries. It does not specify the interoperability requirements for these numeric
identifiers, nor does it suggest an algorithm for generating them.</t>
<t hangText="1993:">
<vspace blankLines="0" /><xref target="Schuba1993"/> describes DNS cache poisoni
ng attacks that require the attacker to guess the Query ID.</t>
<t hangText="June 1995:">
<vspace blankLines="0" /><xref target="Vixie1995"/> suggests that both the UDP s
ource port and the ID of query packets should be randomized, although that might
not provide enough entropy to prevent an attacker from guessing these values.</
t>
<t hangText="April 1997:">
<vspace blankLines="0" /><xref target="Arce1997"/> finds that implementations em
ploy predictable UDP source ports and predictable Query IDs, and argues that bot
h should be randomized.</t>
<t hangText="November 2002:">
<vspace blankLines="0" /><xref target="Sacramento2002"/> finds that by spoofing
multiple requests for the same domain name from different IP addresses, an attac
ker may guess the Query ID employed for a victim with a high probability of succ
ess, thus performing DNS cache poisoning attacks.</t>
<t hangText="July 2007:"> <t>On the other hand, there are a number of IETF protocol specifications t
<vspace blankLines="0" /><xref target="Klein2007b"/> finds that a popular DNS se hat over specify some of their associated transient numeric identifiers. For exa
rver software (BIND 9) that randomizes the Query ID is still subject to DNS cach mple, <xref target="RFC4291" format="default"/> essentially overloads the semant
e poisoning attacks by forging a large number of queries and leveraging the birt ics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in th
hday paradox. e IPv6 IIDs when the interoperability requirement of uniqueness could be achieve
d in other ways that do not result in negative security and privacy implications
<xref target="RFC7721" format="default"/>. Similarly, <xref target="RFC2460" fo
rmat="default"/> suggests the use of a global counter for the generation of Iden
tification values when the interoperability requirement of uniqueness per {IPv6
Source Address, IPv6 Destination Address} could be achieved with other algorithm
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>The following subsections document the timelines for a number of sample
transient numeric identifiers that illustrate how the problem discussed in this
document has affected protocols from different layers over time. These sample t
ransient numeric identifiers have different interoperability requirements and fa
ilure severities (see <xref target="RFC9415" section="6" sectionFormat="of" form
at="default"/>), and thus are considered to be representative of the problem bei
ng analyzed in this document.</t>
<section anchor="ipid" numbered="true" toc="default">
<name>IPv4/IPv6 Identification</name>
<t>This section presents the timeline of the Identification field employ
ed by IPv4 (in the base header) and IPv6 (in Fragment Headers). The reason for p
resenting both cases in the same section is to make it evident that, while the I
dentification value serves the same purpose in both protocols, the work and rese
arch done for the IPv4 case did not influence IPv6 specifications or implementat
ions.</t>
<t>The IPv4 Identification is specified in <xref target="RFC0791" format
="default"/>, which specifies the interoperability requirements for the Identifi
cation field, i.e., the sender must choose the Identification field to be unique
for a given {Source Address, Destination Address, Protocol} for the time the da
tagram (or any fragment of it) could be alive in the Internet. It suggests that
a sending protocol module may keep "a table of Identifiers, one entry for each
destination it has communicated with in the last maximum packet lifetime for the
[I]nternet", and it also suggests that "since the Identifier field allows 65,53
6 different values, hosts may be able to simply use unique identifiers independe
nt of destination". The above has been interpreted numerous times as a suggestio
n to employ per-destination or global counters for the generation of Identificat
ion values. While <xref target="RFC0791" format="default"/> does not suggest any
flawed algorithm for the generation of Identification values, the specification
omits a discussion of the security and privacy implications of predictable Iden
tification values. This resulted in many IPv4 implementations generating predict
able Identification values by means of a global counter, at least at some point
in time.
</t> </t>
<t>
<t hangText="March 2007:"> The IPv6 Identification was originally specified in <xref target="RFC1883" forma
<vspace blankLines="0" /><xref target="Klein2007c"/> finds that Microsoft Window t="default"/>. It serves the same purpose as its IPv4 counterpart, but rather th
s DNS Server generates predictable Query ID values. an being part of the base header (as in the IPv4 case), it is part of the Fragme
nt Header (which may or may not be present in an IPv6 packet). <xref target="RFC
1883" format="default" sectionFormat="of" section ="4.5"/> states that the Ident
ification must be different than that of any other fragmented packet sent recent
ly (within the maximum likely lifetime of a packet) with the same Source Address
and Destination Address. Subsequently, it notes that this requirement can be me
t by means of a wrap-around 32-bit counter that is incremented each time a packe
t must be fragmented and that it is an implementation choice whether to use a gl
obal or a per-destination counter. Thus, the specification of the IPv6 Identific
ation is similar to that of the IPv4 case, with the only difference that, in the
IPv6 case, the suggestions to use simple counters is more explicit. <xref targe
t="RFC2460" format="default"/> is the first revision of the core IPv6 specificat
ion and maintains the same text for the specification of the IPv6 Identification
field. <xref target="RFC8200" format="default"/>, the second revision of the co
re IPv6 specification, removes the suggestion from <xref target="RFC2460" format
="default"/> to use a counter for the generation of IPv6 Identification values a
nd points to <xref target="RFC7739" format="default"/> for sample algorithms for
their generation.
</t> </t>
<dl newline="true" spacing="normal">
<dt>September 1981:</dt>
<dd>
<xref target="RFC0791" format="default"/> specifies the interoperabi
lity requirements for the IPv4 Identification but does not perform a vulnerabili
ty assessment of this transient numeric identifier.
</dd>
<dt>December 1995:</dt>
<dd>
<xref target="RFC1883" format="default"/>, the first specification o
f the IPv6 protocol, is published. It suggests that a counter be used to generat
e the IPv6 Identification values and notes that it is an implementation choice w
hether to maintain a single counter for the node or multiple counters (e.g., one
for each of the node's possible Source Addresses, or one for each active {Sourc
e Address, Destination Address} set).
</dd>
<dt>December 1998:</dt>
<dd>
<xref target="Sanfilippo1998a" format="default"/> finds that predict
able IPv4 Identification values (as generated by most popular implementations) c
an be leveraged to count the number of packets sent by a target node. <xref targ
et="Sanfilippo1998b" format="default"/> explains how to leverage the same vulner
ability to implement a port-scanning technique known as "idle scan". A tool that
implements this attack is publicly released.
</dd>
<dt>December 1998:</dt>
<dd>
<xref target="RFC2460" format="default"/>, a revision of the IPv6 sp
ecification, is published, obsoleting <xref target="RFC1883" format="default"/>.
It maintains the same specification of the IPv6 Identification field as its pre
decessor <xref target="RFC1883" format="default"/>.
</dd>
<dt>December 1998:</dt>
<dd>OpenBSD implements randomization of the IPv4 Identification field
<xref target="OpenBSD-IPv4-ID" format="default"/>.
</dd>
<dt>November 1999:</dt>
<dd>
<xref target="Sanfilippo1999" format="default"/> discusses how to le
verage predictable IPv4 Identification values to uncover the rules of a number o
f firewalls.
</dd>
<dt>September 2002:</dt>
<dd>
<xref target="Fyodor2002" format="default"/> documents the implement
ation of the "idle scan" technique in the popular Network Mapper (nmap) tool.
</dd>
<dt>November 2002:</dt>
<dd>
<xref target="Bellovin2002" format="default"/> explains how the IPv4
Identification field can be exploited to count the number of systems behind a N
AT.
</dd>
<dt>October 2003:</dt>
<dd>OpenBSD implements randomization of the IPv6 Identification field
<xref target="OpenBSD-IPv6-ID" format="default"/>.
</dd>
<dt>December 2003:</dt>
<dd>
<xref target="Zalewski2003" format="default"/> explains a technique
to perform TCP data injection attacks based on predictable IPv4 Identification v
alues, which requires less effort than TCP injection attacks performed with bare
TCP packets.
</dd>
<dt>January 2005:</dt>
<dd>
<xref target="Silbersack2005" format="default"/> discusses shortcomi
ngs in a number of techniques to mitigate predictable IPv4 Identification values
.
</dd>
<dt>October 2007:</dt>
<dd>
<xref target="Klein2007" format="default"/> describes a weakness in
the pseudorandom number generator (PRNG) in use for the generation of IP Identif
ication values by a number of operating systems.
</dd>
<dt>June 2011:</dt>
<dd>
<xref target="Gont2011" format="default"/> describes how to perform
idle scan attacks in IPv6.
</dd>
<dt>November 2011:</dt>
<dd>Linux mitigates predictable IPv6 Identification values <xref targe
t="RedHat2011" format="default"/> <xref target="SUSE2011" format="default"/> <xr
ef target="Ubuntu2011" format="default"/>.
</dd>
<dt>December 2011:</dt>
<dd>
<xref target="draft-gont-6man-predictable-fragment-id-00" format="de
fault"/> describes the security implications of predictable IPv6 Identification
values and possible mitigations. This document has the intended status of "Stand
ards Track", with the intention to formally update <xref target="RFC2460" format
="default"/> to introduce security and privacy requirements on the generation of
IPv6 Identification values.
</dd>
<dt>May 2012:</dt>
<dd>
<xref target="Gont2012" format="default"/> notes that some major IPv
6 implementations still employ predictable IPv6 Identification values.
</dd>
<t hangText="October 2007:"> <dt>March 2013:</dt>
<vspace blankLines="0" /><xref target="Klein2007"/> finds that OpenBSD's DNS sof <dd>The 6man WG adopts <xref target="draft-gont-6man-predictable-fragm
tware (based on ISC's BIND DNS Server) generates predictable Query ID values. ent-id-03" format="default"/> but changes the track to "BCP" (while still formal
</t> ly updating <xref target="RFC2460" format="default"/>), posting the resulting do
cument as <xref target="draft-ietf-6man-predictable-fragment-id-00" format="defa
ult"/>.
</dd>
<dt>June 2013:</dt>
<dd>A patch to incorporate support for IPv6-based idle scans in nmap i
s submitted <xref target="Morbitzer2013" format="default"/>.
</dd>
<dt>December 2014:</dt>
<dd>The 6man WG changes the intended status of <xref target="draft-iet
f-6man-predictable-fragment-id-01" format="default"/> to "Informational" and pos
ts it as <xref target="draft-ietf-6man-predictable-fragment-id-02" format="defau
lt"/>. As a result, it no longer formally updates <xref target="RFC2460" format=
"default"/>, and security and privacy requirements on the generation of IPv6 Ide
ntification values are eliminated.
</dd>
<dt>June 2015:</dt>
<dd>
<xref target="draft-ietf-6man-predictable-fragment-id-08" format="de
fault"/> notes that some popular host and router implementations still employ pr
edictable IPv6 Identification values.
</dd>
<dt>February 2016:</dt>
<dd>
<xref target="RFC7739" format="default"/> (based on <xref target="dr
aft-ietf-6man-predictable-fragment-id-10" format="default"/>) analyzes the secur
ity and privacy implications of predictable IPv6 Identification values and provi
des guidance for selecting an algorithm to generate such values. However, being
published as an "Informational" RFC, it does not formally update <xref target="R
FC2460" format="default"/> and does not introduce security and privacy requireme
nts on the generation of IPv6 Identification values.
</dd>
<dt>June 2016:</dt>
<dd>
<xref target="draft-ietf-6man-rfc2460bis-05" format="default"/>, a d
raft revision of <xref target="RFC2460" format="default"/>, removes the suggesti
on from <xref target="RFC2460" format="default"/> to use a counter for the gener
ation of IPv6 Identification values but does not perform a vulnerability assessm
ent of the generation of IPv6 Identification values and does not introduce secur
ity and privacy requirements on the generation of IPv6 Identification values.
</dd>
<dt>July 2017:</dt>
<dd>
<xref target="draft-ietf-6man-rfc2460bis-13" format="default"/> is f
inally published as <xref target="RFC8200" format="default"/>, obsoleting <xref
target="RFC2460" format="default"/> and pointing to <xref target="RFC7739" forma
t="default"/> for sample algorithms for the generation of IPv6 Identification va
lues. However, it does not introduce security and privacy requirements on the ge
neration of IPv6 Identification values.
</dd>
<dt>October 2019:</dt>
<dd>
<xref target="IPID-DEV" format="default"/> notes that the IPv6 Ident
ification generators of two popular operating systems are flawed.
</dd>
</dl>
</section>
<section anchor="tcp-isns" numbered="true" toc="default">
<name>TCP Initial Sequence Numbers (ISNs)</name>
<t>
<xref target="RFC0793" format="default"/> suggests that the choice of the ISN of
a connection is not arbitrary but aims to reduce the chances of a stale segment
from being accepted by a new incarnation of a previous connection. <xref target
="RFC0793" format="default"/> suggests the use of a global 32-bit ISN generator
that is incremented by 1 roughly every 4 microseconds. However, as a matter of f
act, protection against stale segments from a previous incarnation of the connec
tion is enforced by preventing the creation of a new incarnation of a previous c
onnection before 2*MSL has passed since a segment corresponding to the old incar
nation was last seen (where "MSL" is the "Maximum Segment Lifetime" <xref target
="RFC0793" format="default"/>). This is accomplished by the TIME-WAIT state and
TCP's "quiet time" concept (see <xref target="RFC1323" format="default" sectionF
ormat="of" section="B"/>). Based on the assumption that ISNs are monotonically i
ncreasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of
an incoming SYN segment to perform "heuristics" that enable the creation of a ne
w incarnation of a connection while the previous incarnation is still in the TIM
E-WAIT state (see p. 945 of <xref target="Wright1994" format="default"/>). This
avoids an interoperability problem that may arise when a node establishes connec
tions to a specific TCP end-point at a high rate <xref target="Silbersack2005" f
ormat="default"/>.</t>
<t>The interoperability requirements for TCP ISNs are probably not as cl
early spelled out as one would expect. Furthermore, the suggestion of employing
a global counter in <xref target="RFC0793" format="default"/> negatively affects
the security and privacy properties of the protocol.</t>
<dl newline="true" spacing="normal">
<dt>September 1981:</dt>
<dd>
<xref target="RFC0793" format="default"/> suggests the use of a glob
al 32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However,
such an ISN generator makes it trivial to predict the ISN that a TCP implementa
tion will use for new connections, thus allowing a variety of attacks against TC
P.
</dd>
<t hangText="January 2009:"> <dt>February 1985:</dt>
<vspace blankLines="0" /><xref target="RFC5452"/> is published, requiring resolv <dd>
ers to randomize the Query ID of DNS queries, and to verify that the Query ID of <xref target="Morris1985" format="default"/> is the first to describ
a DNS reply matches that of the DNS query as part of the DNS reply validation p e how to exploit predictable TCP ISNs for forging TCP connections that could the
rocess. n be leveraged for trust relationship exploitation.
</t> </dd>
<dt>April 1989:</dt>
<dd>
<xref target="Bellovin1989" format="default"/> discusses the securit
y considerations for predictable ISNs (along with a range of other protocol-base
d vulnerabilities).
</dd>
<dt>January 1995:</dt>
<dd>
<xref target="Shimomura1995" format="default"/> reports a real-world
exploitation of the vulnerability described in <xref target="Morris1985" format
="default"/> ten years before (in 1985).
</dd>
<dt>May 1996:</dt>
<dd>
<xref target="RFC1948" format="default"/> is the first IETF effort,
authored by Steven Bellovin, to address predictable TCP ISNs. However, <xref tar
get="RFC1948" format="default"/> does not formally update <xref target="RFC0793"
format="default"/>. Note: The same concept specified in this document for TCP I
SNs was later proposed for TCP ephemeral ports <xref target="RFC6056" format="de
fault"/>, TCP Timestamps, and eventually even IPv6 Interface Identifiers <xref t
arget="RFC7217" format="default"/>.
</dd>
<dt>July 1996:</dt>
<dd>OpenBSD implements TCP ISN randomization based on random increment
s (please see <xref target="RFC9415" format="default" sectionFormat="of" section
="A.2"/>) <xref target="OpenBSD-TCP-ISN-I" format="default"/>.
</dd>
<dt>December 2000:</dt>
<dd>OpenBSD implements TCP ISN randomization using simple randomizatio
n (please see <xref target="RFC9415" section="7.1" sectionFormat="of" format="de
fault"/>) <xref target="OpenBSD-TCP-ISN-R" format="default"/>.
</dd>
<dt>March 2001:</dt>
<dd>
<xref target="Zalewski2001" format="default"/> provides a detailed a
nalysis of statistical weaknesses in some TCP ISN generators and includes a surv
ey of the algorithms in use by popular TCP implementations. Vulnerability adviso
ries <xref target="USCERT2001" format="default"/> were released regarding statis
tical weaknesses in some TCP ISN generators, affecting popular TCP implementatio
ns. Other vulnerability advisories on the same vulnerability, such as <xref targ
et="CERT2001" format="default"/>, were published later on.</dd>
<t hangText="May 2010:"> <dt>March 2002:</dt>
<vspace blankLines="0" /><xref target="Economou2010"/> finds that Windows SMTP S <dd>
ervice implements its own DNS resolver that results in predictable Query ID valu <t><xref target="Zalewski2002" format="default"/> updates and comple
es. Additionally, it fails to validate that the Query ID of DNS reply matches th ments <xref target="Zalewski2001" format="default"/>. It concludes that "while s
e one from the DNS query that supposedly elicited the reply. ome vendors [...] reacted promptly and tested their solutions properly, many sti
ll either ignored the issue and never evaluated their implementations, or implem
ented a flawed solution that apparently was not tested using a known approach" <
xref target="Zalewski2002" format="default"/>.</t>
</dd>
<dt>June 2007:</dt>
<dd>OpenBSD implements TCP ISN randomization based on the algorithm sp
ecified in <xref target="RFC1948" format="default"/> (currently obsoleted and re
placed by <xref target="RFC6528" format="default"/>) for the TCP endpoint that p
erforms the active open while keeping the simple randomization scheme for the en
dpoint performing the passive open <xref target="OpenBSD-TCP-ISN-H" format="defa
ult"/>. This provides monotonically increasing ISNs for the "client side" (allow
ing the BSD heuristics to work as expected) while avoiding any patterns in the I
SN generation for the "server side".
</dd>
<dt>February 2012:</dt>
<dd>
<xref target="RFC6528" format="default"/>, published 27 years after
Morris's original work <xref target="Morris1985" format="default"/>, formally up
dates <xref target="RFC0793" format="default"/> to mitigate predictable TCP ISNs
.
</dd>
<dt>August 2014:</dt>
<dd>
The algorithm specified in <xref target="RFC6528" format="default"/>
becomes the recommended ("<bcp14>SHOULD</bcp14>") algorithm for TCP ISN generat
ion in <xref target="draft-eddy-rfc793bis-04"/>, an early revision of the core T
CP specification <xref target="RFC9293"/>.
</dd>
<dt>August 2022:</dt>
<dd>
<xref target="RFC9293" format="default"/>, a revision of the core TCP specificat
ion, is published, adopting the algorithm specified in <xref target="RFC6528" fo
rmat="default"/> as the recommended ("SHOULD") algorithm for TCP ISN generation.
</dd>
</dl>
</section>
<section anchor="ipv6-iids" numbered="true" toc="default">
<name>IPv6 Interface Identifiers (IIDs)</name>
<t>IPv6 Interface Identifiers can be generated as a result of different
mechanisms, including Stateless Address Autoconfiguration (SLAAC) <xref target="
RFC4862" format="default"/>, DHCPv6 <xref target="RFC8415" format="default"/>, a
nd manual configuration. This section focuses on Interface Identifiers resulting
from SLAAC.</t>
<t>The Interface Identifier of stable IPv6 addresses resulting from SLAA
C originally resulted in the underlying link-layer address being embedded in the
IID. At the time, employing the underlying link-layer address for the IID was s
een as a convenient way to obtain a unique address. However, recent awareness ab
out the security and privacy properties of this approach <xref target="RFC7707"
format="default"/> <xref target="RFC7721" format="default"/> has led to the repl
acement of this flawed scheme with an alternative one <xref target="RFC7217" for
mat="default"/> <xref target="RFC8064" format="default"/> that does not negative
ly affect the security and privacy properties of the protocol.
</t> </t>
<dl newline="true" spacing="normal">
<dt>January 1997:</dt>
<dd>
<xref target="RFC2073" format="default"/> specifies the syntax of IP
v6 global addresses (referred to as "An IPv6 Provider-Based Unicast Address Form
at" at the time), which is consistent with the IPv6 addressing architecture spec
ified in <xref target="RFC1884" format="default"/>.
Hosts are recommended to "generate addresses using link-specific addr
esses as Interface ID such as 48 bit IEEE-802 MAC addresses".
</dd>
<dt>July 1998:</dt>
<dd>
<xref target="RFC2374" format="default"/> specifies "An IPv6 Aggrega
table Global Unicast Address Format" (obsoleting <xref target="RFC2073" format="
default"/>), changing the size of the IID to 64 bits, and specifies that IIDs mu
st be constructed in IEEE 64-bit Extended Unique Identifier (EUI-64) format. How
such identifiers are constructed is specified in the corresponding "IPv6 over &
lt;link&gt;" specifications, such as "IPv6 over Ethernet".
</dd>
<dt>January 2001:</dt>
<dd>
<xref target="RFC3041" format="default"/> recognizes the problem of
IPv6 network activity correlation and specifies IPv6 temporary addresses. Tempor
ary addresses are to be used along with stable addresses.
</dd>
<dt>August 2003:</dt>
<dd>
<xref target="RFC3587" format="default"/> obsoletes <xref target="RF
C2374" format="default"/>, making the Top-Level Aggregator (TLA) / Next-Level
Aggregator (NLA) structure historic, though the syntax and recommendations fo
r the stable IIDs remain unchanged.
</dd>
<dt>February 2006:</dt>
<dd>
<xref target="RFC4291" format="default"/> is published as the latest
"IP Version 6 Addressing Architecture", requiring the IIDs of "all unicast addr
esses, except those that start with the binary value 000" to employ the Modified
EUI-64 format. The details of constructing such interface identifiers are defin
ed in the corresponding "IPv6 over &lt;link&gt;" specifications.
</dd>
<dt>March 2008:</dt>
<dd>
<xref target="RFC5157" format="default"/> provides hints regarding h
ow patterns in IPv6 addresses could be leveraged for the purpose of address scan
ning.
</dd>
<dt>December 2011:</dt>
<dd>
<xref target="draft-gont-6man-stable-privacy-addresses-00" format="d
efault"/> notes that the original scheme for generating stable addresses allows
for IPv6 address scanning and for active host tracking (even when IPv6 temporary
addresses are employed). It also specifies an alternative algorithm meant to re
place IIDs based on Modified EUI-64 format identifiers.
</dd>
<dt>November 2012:</dt>
<dd>The 6man WG adopts <xref target="draft-gont-6man-stable-privacy-ad
dresses-01" format="default"/> as a working group item (as <xref target="draft-i
etf-6man-stable-privacy-addresses-00" format="default"/>). However, the document
no longer formally updates <xref target="RFC4291" format="default"/>; therefore
, the specified algorithm no longer formally replaces the Modified EUI-64 format
identifiers.
</dd>
<dt>February 2013:</dt>
<dd>An address-scanning tool (scan6 of <xref target="IPv6-Toolkit" for
mat="default"/>) that leverages IPv6 address patterns is released <xref target="
Gont2013" format="default"/>.
</dd>
<dt>July 2013:</dt>
<dd>
<xref target="draft-cooper-6man-ipv6-address-generation-privacy-00"
format="default"/> elaborates on the security and privacy properties of all know
n algorithms for generating IPv6 IIDs.
</dd>
<dt>January 2014:</dt>
<dd>The 6man WG posts <xref target="draft-ietf-6man-default-iids-00" f
ormat="default"/> ("Recommendation on Stable IPv6 Interface Identifiers"), recom
mending <xref target="draft-ietf-6man-stable-privacy-addresses-17" format="defau
lt"/> for the generation of stable addresses.
</dd>
<dt>April 2014:</dt>
<dd>
</list> <xref target="RFC7217" format="default"/> (formerly <xref target="dr
</t> aft-ietf-6man-stable-privacy-addresses-17" format="default"/>) is published, spe
</section> cifying "A Method for Generating Semantically Opaque Interface Identifiers with
IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but <str
ong>not</strong> replacement of) Modified EUI-64 format IIDs.
</dd>
<dt>March 2016:</dt>
<dd>
<xref target="RFC7707" format="default"/> (formerly <xref target="dr
aft-gont-opsec-ipv6-host-scanning-02" format="default"/> and later <xref target=
"draft-ietf-opsec-ipv6-host-scanning-08" format="default"/>), about "Network Rec
onnaissance in IPv6 Networks", is published.
</dd>
<dt>March 2016:</dt>
<dd>
<xref target="RFC7721" format="default"/> (formerly <xref target="dr
aft-cooper-6man-ipv6-address-generation-privacy-00" format="default"/> and later
<xref target="draft-ietf-6man-ipv6-address-generation-privacy-08" format="defau
lt"/>), about "Security and Privacy Considerations for IPv6 Address Generation M
echanisms", is published.
</dd>
<dt>May 2016:</dt>
<dd>
<xref target="draft-gont-6man-non-stable-iids-00" format="default"/>
is posted, with the goal of specifying requirements for non-stable addresses an
d updating <xref target="RFC4941" format="default"/> such that use of only tempo
rary addresses is allowed.
</dd>
<dt>May 2016:</dt>
<dd>
<xref target="draft-gont-6man-address-usage-recommendations-00" form
at="default"/> is posted, providing an analysis of how different aspects on an a
ddress (from stability to usage mode) affect their corresponding security and pr
ivacy properties and meaning to eventually provide advice in this area.
</dd>
<dt>February 2017:</dt>
<dd><xref target="draft-ietf-6man-default-iids-16" format="default"/>,
produced by the 6man WG, is published as <xref target="RFC8064" format="default
"/> ("Recommendation on Stable IPv6 Interface Identifiers"), with requirements f
or stable addresses and a recommendation to employ <xref target="RFC7217" format
="default"/> for the generation of stable addresses. It formally updates a large
number of RFCs.
</dd>
<dt>March 2018:</dt>
<dd>
<xref target="draft-fgont-6man-rfc4941bis-00" format="default"/> is
posted (as suggested by the 6man WG) to address flaws in <xref target="RFC4941"
format="default"/> by revising it (as an alternative to the <xref target="draft-
gont-6man-non-stable-iids-00" format="default"/> effort, posted in March 2016).
</dd>
<dt>July 2018:</dt>
<dd>
<xref target="draft-fgont-6man-rfc4941bis-00" format="default"/> is
adopted (as <xref target="draft-ietf-6man-rfc4941bis-00" format="default"/>) as
a WG item of the 6man WG.
</dd>
<dt>December 2020:</dt>
<dd>
<xref target="draft-ietf-6man-rfc4941bis-12" format="default"/> is a
pproved by the IESG for publication as an RFC.
</dd>
<dt>February 2021:</dt>
<dd>
<xref target="draft-ietf-6man-rfc4941bis-12" format="default"/> is f
inally published as <xref target="RFC8981" format="default"/>.
</dd>
</dl>
</section>
<section anchor="ntp-refid" numbered="true" toc="default">
<name>NTP Reference IDs (REFIDs)</name>
<t>The NTP <xref target="RFC5905" format="default"/> Reference ID is a 3
2-bit code identifying the particular server or reference clock. Above stratum 1
(secondary servers and clients), this value can be employed to avoid degree-one
timing loops, that is, scenarios where two NTP peers are (mutually) the time so
urce of each other. If using the IPv4 address family, the identifier is the four
-octet IPv4 address. If using the IPv6 address family, it is the first four oct
ets of the MD5 hash of the IPv6 address.</t>
<dl newline="true" spacing="normal">
<dt>June 2010:</dt>
<dd>
<xref target="RFC5905" format="default"/> ("Network Time Protocol Ve
rsion 4: Protocol and Algorithms Specification") is published. It specifies that
, for NTP peers with stratum higher than 1, the REFID embeds the IPv4 address of
the time source or the first four octets of the MD5 hash of the IPv6 address of
the time source.
</dd>
<dt>July 2016:</dt>
<dd>
<xref target="draft-stenn-ntp-not-you-refid-00" format="default"/> i
s posted, describing the information leakage produced via the NTP REFID. It prop
oses that NTP returns a special REFID when a packet employs an IP Source Address
that is not believed to be a current NTP peer but otherwise generates and retur
ns the common REFID. It is subsequently adopted by the NTP WG as <xref target="d
raft-ietf-ntp-refid-updates-00" format="default"/>.
</dd>
<dt>April 2019:</dt>
<dd>
<xref target="Gont-NTP" format="default"/> notes that the proposed f
ix specified in <xref target="draft-ietf-ntp-refid-updates-00" format="default"/
> is, at the very least, sub-optimal. As a result of a lack of WG support, the <
xref target="draft-ietf-ntp-refid-updates-00" format="default"/> effort is event
ually abandoned.
</dd>
</dl>
</section>
<section anchor="port-numbers" numbered="true" toc="default">
<name>Transport-Protocol Ephemeral Port Numbers</name>
<t>Most (if not all) transport protocols employ "port numbers" to demult
iplex packets to the corresponding transport-protocol instances. "Ephemeral port
s" refer to the local ports employed in active OPEN requests, that is, typically
the local port numbers employed on the side initiating the communication.</t>
</section> <dl newline="true" spacing="normal">
<dt>August 1980:</dt>
<dd>
<xref target="RFC0768" format="default"/> notes that the UDP source
port is optional and identifies the port of the sending process. It does not spe
cify interoperability requirements for source port selection, nor does it sugges
t possible ways to select port numbers. Most popular implementations end up sele
cting source ports from a system-wide global counter.</dd>
<dt>September 1981:</dt>
<dd>
<xref target="RFC0793" format="default"/> (the TCP specification) es
sentially describes the use of port numbers and specifies that port numbers shou
ld result in a unique socket pair {local address, local port, remote address, re
mote port}. How ephemeral ports are selected and the port range from which they
are selected are left unspecified.
</dd>
<dt>July 1996:</dt>
<dd>OpenBSD implements ephemeral port randomization <xref target="Open
BSD-PR" format="default"/>.
</dd>
<dt>July 2008:</dt>
<dd>The CERT Coordination Center publishes details of what became know
n as the "Kaminsky Attack" <xref target="VU-800113" format="default"/> <xref tar
get="Kaminsky2008" format="default"/> on the DNS. The attack exploits the lack o
f ephemeral port randomization and DNS ID randomization in many major DNS implem
entations to perform cache poisoning in an effective and practical manner.
</dd>
<dt>January 2009:</dt>
<dd>
<xref target="RFC5452" format="default"/> mandates the use of port r
andomization for DNS resolvers and mandates that implementations must randomize
ports from the range of available ports (53 or 1024 and above) that is as large
as possible and practicable. It does not recommend possible algorithms for port
randomization, although the document specifically targets DNS resolvers, for whi
ch a simple port randomization suffices (e.g., Algorithm 1 of <xref target="RFC6
056" format="default"/>). This document led to the implementation of port random
ization in the DNS resolvers themselves, rather than in the underlying transport
protocols.
</dd>
<dt>January 2011:</dt>
<dd>
<xref target="RFC6056" format="default"/> notes that many TCP and UD
P implementations result in predictable ephemeral port numbers and also notes th
at many implementations select port numbers from a small portion of the whole po
rt number space. It recommends the implementation and use of ephemeral port rand
omization, proposes a number of possible algorithms for port randomization, and
also recommends to randomize port numbers over the range 1024-65535.
</dd>
<dt>March 2016:</dt>
<dd>
<xref target="NIST-NTP" format="default"/> reports a non-normal dist
ribution of the ephemeral port numbers employed by the NTP clients of an Interne
t Time Service.
</dd>
<dt>April 2019:</dt>
<dd>
<xref target="draft-gont-ntp-port-randomization-00" format="default"
/> notes that some NTP implementations employ the NTP service port (123) as the
local port for nonsymmetric modes and aims to update the NTP specification to re
commend port randomization in such cases, which is in line with <xref target="RF
C6056" format="default"/>. The proposal experiences some pushback in the relevan
t working group (NTP WG) <xref target="NTP-PORTR" format="default"/> but is fina
lly adopted as a working group item as <xref target="draft-ietf-ntp-port-randomi
zation-00" format="default"/>.
</dd>
<dt>August 2021:</dt>
<dd>
<xref target="draft-ietf-ntp-port-randomization-08" format="default"
/> is finally published as <xref target="RFC9109" format="default"/>.
</dd>
</dl>
</section>
<section anchor="dns-query-id" numbered="true" toc="default">
<name>DNS ID</name>
<t>The DNS ID <xref target="RFC1035" format="default"/> can be employed
to match DNS replies to outstanding DNS queries.</t>
<aside>
<t>NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".</t>
</aside>
<section title="Conclusions" anchor="conclusions"> <dl newline="true" spacing="normal">
<t> <dt>November 1987:</dt>
For more than 30 years, a large number of implementations of the IETF protoco <dd>
ls have been subject to a variety of attacks, with <xref target="RFC1035" format="default"/> specifies that the DNS ID
effects ranging from Denial of Service (DoS) or data injection, to is a 16-bit identifier assigned by the program that
generates any kind of query and that this identifier is copied in the correspond
ing reply and can be used by the requester to match up replies to outstanding qu
eries. It does not specify the interoperability requirements for this numeric id
entifier, nor does it suggest an algorithm for generating it.</dd>
<dt>August 1993:</dt>
<dd>
<xref target="Schuba1993" format="default"/> describes DNS cache poi
soning attacks that require the attacker to guess the DNS ID.</dd>
<dt>June 1995:</dt>
<dd>
<xref target="Vixie1995" format="default"/> suggests that both the U
DP source port and the DNS ID of query packets should be randomized, although th
at might not provide enough entropy to prevent an attacker from guessing these v
alues.</dd>
<dt>April 1997:</dt>
<dd>
<xref target="Arce1997" format="default"/> finds that implementation
s employ predictable UDP source ports and predictable DNS IDs and argues that bo
th should be randomized.</dd>
<dt>November 2002:</dt>
<dd>
<xref target="Sacramento2002" format="default"/> finds that, by spoo
fing multiple requests for the same domain name from different IP addresses, an
attacker may guess the DNS ID employed for a victim with a high probability of s
uccess, thus allowing for DNS cache poisoning attacks.</dd>
<dt>March 2007:</dt>
<dd>
<xref target="Klein2007c" format="default"/> finds that the Microsof
t Windows DNS server generates predictable DNS ID values.
</dd>
<dt>July 2007:</dt>
<dd>
<xref target="Klein2007b" format="default"/> finds that a popular DN
S server software (BIND 9) that randomizes the DNS ID is still subject to DNS ca
che poisoning attacks by forging a large number of queries and leveraging the bi
rthday paradox.
</dd>
<dt>October 2007:</dt>
<dd>
<xref target="Klein2007" format="default"/> finds that OpenBSD's DNS
software (based on the BIND DNS server of the Internet Systems Consortium (ISC)
) generates predictable DNS ID values.
</dd>
<dt>January 2009:</dt>
<dd>
<xref target="RFC5452" format="default"/> is published, requiring re
solvers to randomize the DNS ID of queries and to verify that the DNS ID of a re
ply matches that of the DNS query as part of the DNS reply validation process.
</dd>
<dt>May 2010:</dt>
<dd>
<xref target="Economou2010" format="default"/> finds that the Window
s SMTP Service implements its own DNS resolver that results in predictable DNS I
D values. Additionally, it fails to validate that the DNS ID of a reply matches
that of the DNS query that supposedly elicited it.
</dd>
</dl>
</section>
</section>
<section anchor="conclusions" numbered="true" toc="default">
<name>Conclusions</name>
<t>
For more than 30 years, a large number of implementations of IETF protocols h
ave been subject to a variety of attacks, with
effects ranging from Denial of Service (DoS) or data injection to
information leakages that could be exploited for pervasive monitoring information leakages that could be exploited for pervasive monitoring
<xref target="RFC7258"/>. The root cause of these issues has been, in many c <xref target="RFC7258" format="default"/>. The root cause of these issues ha
ases, s been, in many cases, the poor selection of transient numeric identifiers in su
poor selection of transient numeric identifiers, usually as a result ch protocols, usually as a result of insufficient or misleading specifications.
of insufficient or misleading specifications.
</t> </t>
<t>
<t>
While it is generally possible to identify an algorithm that can While it is generally possible to identify an algorithm that can
satisfy the interoperability requirements for a given transient satisfy the interoperability requirements for a given transient
numeric identifier, this document provides empirical evidence that numeric identifier, this document provides empirical evidence that
doing so without negatively affecting the security or privacy doing so without negatively affecting the security and/or privacy
properties of the aforementioned protocols is non-trivial. It is thus properties of the aforementioned protocols is nontrivial. It is thus
evident that advice in this area is warranted. evident that advice in this area is warranted.
</t> </t>
<t>
<t> <xref target="RFC9416" format="default"/> aims at requiring future
<xref target="I-D.gont-numeric-ids-sec-considerations"/> aims at requiring fu
ture
IETF protocol specifications to contain analysis of the security and IETF protocol specifications to contain analysis of the security and
privacy properties of any transient numeric identifiers specified by privacy properties of any transient numeric identifiers specified by
the protocol, and to recommend an algorithm for the generation the protocol and to recommend an algorithm for the generation
of such transient numeric identifiers. <xref target="I-D.irtf-pearg-numeric-i of such transient numeric identifiers. <xref target="RFC9415" format="default
ds-generation"/> specifies a number of sample algorithms for generating "/> specifies a number of sample algorithms for generating
transient numeric identifiers with specific interorability transient numeric identifiers with specific interoperability
requirements and failure severities. requirements and failure severities.
</t> </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 document analyzes the timeline of the specification and implementation o
f the transient numeric identifiers of some sample IETF protocols, and how the s
ecurity and privacy properties of such protocols have been affected as a result
of it. It provides concrete evidence that advice in this area is warranted.</t>
<t><xref target="I-D.gont-numeric-ids-sec-considerations"/> formally requires IE
TF protocol specifications to specify the interoperability requirements for thei
r transient numeric identifiers, to do a warranted vulnerability assessment of s
uch transient numeric identifiers, and to recommend possible algorithms for thei
r generation, such that the interoperability requirements are complied with, whi
le any negative security and privacy properties of these transient numeric ident
ifiers are mitigated.</t>
<t><xref target="I-D.irtf-pearg-numeric-ids-generation"/> analyzes and categoriz
es transient numeric identifiers based on their interoperability requirements an
d their associated failure severities, and recommends possible algorithms that c
an comply with those requirements without negatively affecting the security and
privacy properties of the corresponding protocols.</t>
</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, Dave C </section>
rocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson, Guillermo Gont, Christia <section numbered="true" toc="default">
n Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe Touch, Brian Trammell <name>Security Considerations</name>
, and Christopher Wood, for providing valuable comments on earlier versions of t <t>This document analyzes the timeline of the specification and implementa
his document.</t> tion of the transient numeric identifiers of some sample IETF protocols and how
the security and privacy properties of such protocols have been affected as a re
<t>The authors would like to thank (in alphabetical order) Steven Bellovin, Jose sult of it. It provides concrete evidence that advice in this area is warranted.
ph Lorenzo Hall, Gre Norcie, and Martin Thomson, for providing valuable comments </t>
on <xref target="I-D.gont-predictable-numeric-ids"/>, on which this document is <t><xref target="RFC9415" format="default"/> analyzes and categorizes tran
based.</t> sient numeric identifiers based on their interoperability requirements and their
associated failure severities and recommends possible algorithms that can be em
<t><xref target="tcp-isns"/> of this document borrows text from <xref target="RF ployed to comply with those requirements without negatively affecting the securi
C6528"/>, authored by Fernando Gont and Steven Bellovin.</t> ty and privacy properties of the corresponding protocols.</t>
<t><xref target="RFC9416" format="default"/> formally requires IETF protoc
<t>The authors would like to thank Sara Dickinson and Christopher Wood, for thei ol specifications to specify the interoperability requirements for their transie
r guidance during the publication process of this document.</t> nt numeric identifiers, to do a warranted vulnerability assessment of such trans
ient numeric identifiers, and to recommend possible algorithms for their generat
<t>The authors would like to thank Diego Armando Maradona for his magic and ins ion, such that the interoperability requirements are complied with, while any ne
piration.</t> gative security or privacy properties of these transient numeric identifiers are
mitigated.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <references>
<!--
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2119" ?>
<!-- UDP -->
<?rfc include="reference.RFC.0768" ?>
<!-- TCP sequence numbers -->
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.6528" ?> <!-- TCP SEQ randomization -->
<!-- IPv4-->
<?rfc include="reference.RFC.0791" ?>
<!-- IPv6 -->
<?rfc include="reference.RFC.1883" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.8200" ?>
<!-- Randomness requirements-->
<!--
<?rfc include="reference.RFC.4086" ?>
<!--
<?rfc include="reference.RFC.6151" ?>
<!-- IPv6 Addresses -->
<?rfc include="reference.RFC.7217" ?>
<?rfc include="reference.RFC.3041" ?>
<?rfc include="reference.RFC.2073" ?>
<?rfc include="reference.RFC.2374" ?>
<?rfc include="reference.RFC.3587" ?>
<?rfc include="reference.RFC.1884" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.2373" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.8415" ?>
<!-- TCP ISNs -->
<?rfc include="reference.RFC.1323" ?>
<!-- Port randomization -->
<?rfc include="reference.RFC.6056" ?>
<?rfc include="reference.RFC.5452" ?>
</references>
<references title='Informative References'>
<reference anchor="OpenBSD-PR" target="https://cvsweb.openbsd.org/src/sys
/netinet/in_pcb.c?rev=1.6">
<front>
<title>Implementation of port randomization</title>
<author>
<organization>OpenBSD</organization>
</author>
<date day="29" month="July" year="1996"/>
</front>
</reference>
<reference anchor="VU-800113" target="https://www.kb.cert.org/vul
s/id/800113">
<front>
<title>Multiple DNS implementations vulnerable to cache p
oisoning (Vulnerability Note VU#800113)</title>
<author>
<organization>CERT/CC</organization>
</author>
<date day="8" month="July" year="2008"/>
</front>
</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>
<!-- IPv6 Addresses -->
<?rfc include="reference.RFC.5157" ?>
<?rfc include="reference.RFC.8981" ?>
<?rfc include="reference.I-D.ietf-6man-rfc4941bis" ?>
<?rfc include="reference.I-D.gont-opsec-ipv6-host-scanning" ?>
<?rfc include="reference.I-D.ietf-opsec-ipv6-host-scanning" ?>
<?rfc include="reference.I-D.gont-6man-stable-privacy-addresses" ?>
<?rfc include="reference.I-D.ietf-6man-stable-privacy-addresses" ?>
<?rfc include="reference.I-D.cooper-6man-ipv6-address-generation-privacy"
?>
<?rfc include="reference.I-D.ietf-6man-ipv6-address-generation-privacy" ?
>
<reference anchor="Gont2013" target="https://lists.si6networks.com/piperm
ail/ipv6hackers/2013-February/000947.html">
<front>
<title>Beta release of the SI6 Network's IPv6 Toolkit (he
lp wanted!)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date year="2013"/>
</front>
<seriesInfo name="Message posted to the IPv6 Hackers mailing-list
" value=" Message-ID: &lt;51184548.3030105@si6networks.com&gt;"/>
</reference>
<reference anchor="IPv6-Toolkit" target="https://www.si6networks.com/tool
s/ipv6toolkit">
<front>
<title>SI6 Networks' IPv6 Toolkit</title>
<author>
<organization>SI6 Networks</organization>
</author>
<date/>
</front>
</reference>
<reference anchor='draft-gont-6man-stable-privacy-addresses-00'>
<front>
<title>A method for Generating Stable Privacy-Enhanced Addresses with IPv
6 Stateless Address Autoconfiguration (SLAAC)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date month='December' day='15' year='2011' />
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-stable-privacy-a
ddresses-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-stable-privacy-
addresses-00.txt' />
</reference>
<reference anchor='draft-ietf-6man-stable-privacy-addresses-00'>
<front>
<title>A method for Generating Stable Privacy-Enhanced Addresses with IPv
6 Stateless Address Autoconfiguration (SLAAC)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date month='May' day='18' year='2012' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-stable-privacy-a
ddresses-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-stable-privacy-
addresses-00.txt' />
</reference>
<reference anchor='draft-gont-6man-address-usage-recommendations-00'>
<front>
<title>IPv6 Address Usage Recommendations</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<author initials="W." surname="Liu" fullname="Will Liu">
</author>
<date month='May' day='27' year='2016' />
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-address-usage-re
commendations-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-address-usage-r
ecommendations-00.txt' />
</reference>
<reference anchor='draft-gont-6man-non-stable-iids-00'>
<front>
<title>Recommendation on Non-Stable IPv6 Interface Identifiers</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<author initials="W." surname="Liu" fullname="Will Liu">
</author>
<date month='May' day='23' year='2016' />
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-non-stable-iids-
00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-non-stable-iids
-00.txt' />
</reference>
<reference anchor='draft-ietf-6man-default-iids-00'>
<front>
<title>Recommendation on Stable IPv6 Interface Identifiers</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<author initials="A." surname="Cooper" fullname="Alissa Cooper">
</author>
<author
fullname="Dave Thaler"
initials="D."
surname="Thaler">
</author>
<author initials="W." surname="Liu" fullname="Will Liu">
</author>
<date month='July' day='28' year='2014' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-default-iids-00'
/>
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-default-iids-00
.txt' />
</reference>
<?rfc include="reference.RFC.8064" ?>
<reference anchor='draft-ietf-6man-rfc4941bis-00'>
<front>
<title abbrev="Privacy Extensions to Autoconf">Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks /
UTN-FRH</organization>
</author>
<author initials="S.K." surname="Krishnan"
fullname="Suresh Krishnan">
<organization>Ericsson Research</organization>
</author>
<author initials="T.N." surname="Narten"
fullname="Thomas Narten">
<organization>IBM Corporation</organization>
</author>
<author initials="R.D." surname="Draves"
fullname="Richard Draves">
<organization>Microsoft Research</organization>
</author>
<date month='July' day='2' year='2018' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-rfc4941bis-00' /
>
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-00.t
xt' />
</reference>
<reference anchor='draft-fgont-6man-rfc4941bis-00'>
<front>
<title abbrev="Privacy Extensions to Autoconf">Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks /
UTN-FRH</organization>
</author>
<author initials="S.K." surname="Krishnan"
fullname="Suresh Krishnan">
<organization>Ericsson Research</organization>
</author>
<author initials="T.N." surname="Narten"
fullname="Thomas Narten">
<organization>IBM Corporation</organization>
</author>
<author initials="R.D." surname="Draves"
fullname="Richard Draves">
<organization>Microsoft Research</organization>
</author>
<date month='March' day='25' year='2018' /> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6528.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1883.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3041.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2073.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2374.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3587.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1884.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4941.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1323.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6056.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5452.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
323.xml"/>
</front> </references>
<references>
<name>Informative References</name>
<seriesInfo name='Internet-Draft' value='draft-fgont-6man-rfc4941bis-00' <reference anchor="OpenBSD-PR" target="https://cvsweb.openbsd.org/src/sy
/> s/netinet/in_pcb.c?rev=1.6">
<format type='TXT' <front>
target='https://tools.ietf.org/id/draft-fgont-6man-rfc4941bis-00. <title>Implementation of port randomization</title>
txt' /> <author>
</reference> <organization>OpenBSD</organization>
</author>
<date month="July" year="1996"/>
</front>
</reference>
<?rfc include="reference.I-D.ietf-6man-default-iids" ?> <reference anchor="VU-800113" target="https://www.kb.cert.org/vuls/id/80
<?rfc include="reference.RFC.7721" ?> 0113">
<?rfc include="reference.RFC.7707" ?> <front>
<title>Multiple DNS implementations vulnerable to cache poisoning</t
itle>
<author>
<organization>CERT/CC</organization>
</author>
<date month="July" year="2008"/>
</front>
<refcontent>Vulnerability Note VU#800113</refcontent>
</reference>
<!-- <reference anchor="IANA-PROT" target="https://www.iana.org/protocols">
<reference anchor="FIPS-SHS" target="http://csrc.nist.gov/publications/fi <front>
ps/fips180-4/fips-180-4.pdf"> <title>Protocol Registries</title>
<front> <author>
<title>Secure Hash Standard (SHS)</title> <organization>IANA</organization>
<author initials="" surname="FIPS" fullname="FIPS"> </author>
<organization></organization> </front>
</author>
<date month="March" year="2012"/>
</front>
<seriesInfo name="" value="Federal Information Processing Standar
ds Publication 180-4"/>
</reference> </reference>
-->
<?rfc include="reference.I-D.gont-predictable-numeric-ids" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5157.xml"
<?rfc include="reference.I-D.gont-numeric-ids-sec-considerations" ?> />
<?rfc include="reference.I-D.irtf-pearg-numeric-ids-generation" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"
/>
<?rfc include="reference.I-D.ietf-6man-rfc2460bis" ?>
<!-- NTP --> <reference anchor="draft-ietf-6man-rfc4941bis-12" target="https://www.ietf.org/a
rchive/id/draft-ietf-6man-rfc4941bis-12.txt">
<front>
<title>
Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
</title>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<organization>SI6 Networks</organization>
</author>
<author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
<organization>Kaloom</organization>
</author>
<author initials="T." surname="Narten" fullname="Dr. Thomas Narten"> </author>
<author initials="R." surname="Draves" fullname="Richard P. Draves">
<organization>Microsoft Research</organization>
</author>
<date month="November" day="2" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc4941bis-12"/>
</reference>
<reference anchor='draft-stenn-ntp-not-you-refid-00'> <reference anchor="draft-gont-opsec-ipv6-host-scanning-02" target="https://www.i
<front> etf.org/archive/id/draft-gont-opsec-ipv6-host-scanning-02.txt">
<title abbrev="Not You REFID">Network Time Protocol Not You REFID</ti <front>
tle> <title>Network Reconnaissance in IPv6 Networks</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Tim Chown" initials="T." surname="Chown"/>
<date day="23" month="October" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-opsec-ipv6-host-scanning-0
2"/>
</reference>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg"> <reference anchor="draft-ietf-opsec-ipv6-host-scanning-08" target="https://www.i
etf.org/archive/id/draft-ietf-opsec-ipv6-host-scanning-08.txt">
<front>
<title>Network Reconnaissance in IPv6 Networks</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Tim Chown" initials="T." surname="Chown"/>
<date day="28" month="August" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsec-ipv6-host-scanning-0
8"/>
</reference>
<organization>Boston University</organization> <reference anchor="draft-gont-6man-stable-privacy-addresses-01" target="https://
www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-01.txt">
<front>
<title>
A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Ad
dress Autoconfiguration (SLAAC)
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="31" month="March" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-6man-stable-privacy-addresse
s-01"/>
</reference>
</author> <reference anchor="draft-ietf-6man-stable-privacy-addresses-17" target="https://
www.ietf.org/archive/id/draft-ietf-6man-stable-privacy-addresses-17.txt">
<front>
<title>A Method for Generating Semantically Opaque Interface Identifiers wit
h IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="27" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-stable-privacy-addr
esses-17"/>
</reference>
<author initials="H." surname="Stenn" <reference anchor="draft-cooper-6man-ipv6-address-generation-privacy-00" target=
fullname="Harlan Stenn"> "https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-address-generation-priva
<organization>Network Time Foundation</organization> cy-00.txt">
<front>
<title>Privacy Considerations for IPv6 Address Generation Mechanisms</title>
<author fullname="Alissa Cooper" initials="A." surname="Cooper"/>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Dave Thaler" initials="D." surname="Thaler"/>
<date day="15" month="July" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-cooper-6man-ipv6-address-gene
ration-privacy-00"/>
</reference>
</author> <reference anchor="draft-ietf-6man-ipv6-address-generation-privacy-08" target="h
ttps://www.ietf.org/archive/id/draft-ietf-6man-ipv6-address-generation-privacy-0
8.txt">
<front>
<title>Privacy Considerations for IPv6 Address Generation Mechanisms</title>
<author fullname="Alissa Cooper" initials="A." surname="Cooper"/>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Dave Thaler" initials="D." surname="Thaler"/>
<date day="23" month="September" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-ipv6-address-generati
on-privacy-08"/>
</reference>
<date month='July' day='8' year='2016' /> <reference anchor="Gont2013" target="https://lists.si6networks.com/piper
mail/ipv6hackers/2013-February/000947.html">
<front>
<title>Beta release of the SI6 Network's IPv6 Toolkit (help wanted!)
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date day="11" year="2013" month="February"/>
</front>
<refcontent>message to the IPv6 Hackers mailing list</refcontent>
</reference>
</front> <reference anchor="IPv6-Toolkit" target="https://www.si6networks.com/too
ls/ipv6toolkit">
<front>
<title>IPv6 Toolkit</title>
<author>
<organization>SI6 Networks</organization>
</author>
</front>
</reference>
<seriesInfo name='Internet-Draft' value='draft-stenn-ntp-not-you-refid-00 <reference anchor="draft-gont-6man-stable-privacy-addresses-00" target="https://
' /> www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-00.txt">
<format type='TXT' <front>
target='https://tools.ietf.org/id/draft-stenn-ntp-not-you-refid-0 <title>
0.txt' /> A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Ad
</reference> dress Autoconfiguration (SLAAC)
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="15" month="December" year="2011"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-6man-stable-privacy-addresse
s-00"/>
</reference>
<reference anchor='draft-ietf-ntp-refid-updates-00'> <reference anchor="draft-ietf-6man-stable-privacy-addresses-00" target="https://
<front> www.ietf.org/archive/id/draft-ietf-6man-stable-privacy-addresses-00.txt">
<title abbrev="Not You REFID">Network Time Protocol Not You REFID</ti <front>
tle> <title>
A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Ad
dress Autoconfiguration (SLAAC)
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="18" month="May" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-stable-privacy-addresse
s-00"/>
</reference>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg"> <reference anchor="draft-gont-6man-address-usage-recommendations-00" target="htt
ps://www.ietf.org/archive/id/draft-gont-6man-address-usage-recommendations-00.tx
t">
<front>
<title>IPv6 Address Usage Recommendations</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Will (Shucheng) LIU" initials="W." surname="LIU"/>
<date day="27" month="May" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-6man-address-usage-recommend
ations-00"/>
</reference>
<organization>Boston University</organization> <reference anchor="draft-gont-6man-non-stable-iids-00" target="https://www.ietf.
org/archive/id/draft-gont-6man-non-stable-iids-00.txt">
<front>
<title>
Recommendation on Non-Stable IPv6 Interface Identifiers
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Will (Shucheng) Liu" initials="W." surname="Liu"/>
<date day="23" month="May" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-6man-non-stable-iids-00"/>
</reference>
</author> <reference anchor="draft-ietf-6man-default-iids-00" target="https://www.ietf.org
/archive/id/draft-ietf-6man-default-iids-00.txt">
<front>
<title>
Recommendation on Stable IPv6 Interface Identifiers
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Alissa Cooper" initials="A." surname="Cooper"/>
<author fullname="Dave Thaler" initials="D." surname="Thaler"/>
<author fullname="Will (Shucheng) Liu" initials="W." surname="Liu"/>
<date day="24" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-default-iids-00"/>
</reference>
<author initials="H." surname="Stenn" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"
fullname="Harlan Stenn"> />
<organization>Network Time Foundation</organization>
</author> <reference anchor="draft-ietf-6man-rfc4941bis-00" target="https://www.ietf.org/a
rchive/id/draft-ietf-6man-rfc4941bis-00.txt">
<front>
<title>
Privacy Extensions for Stateless Address Autoconfiguration in IPv6
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson Research</organization>
</author>
<author fullname="Dr. Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>
</author>
<author fullname="Richard P. Draves" initials="R." surname="Draves">
<organization>Microsoft Research</organization>
</author>
<date day="2" month="July" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc4941bis-00"/>
</reference>
<date month='November' day='13' year='2016' /> <reference anchor="draft-fgont-6man-rfc4941bis-00" target="https://www.ietf.org/
archive/id/draft-fgont-6man-rfc4941bis-00.txt">
<front>
<title>
Privacy Extensions for Stateless Address Autoconfiguration in IPv6
</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson Research</organization>
</author>
<author fullname="Dr. Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>
</author>
<author fullname="Richard P. Draves" initials="R." surname="Draves">
<organization>Microsoft Research</organization>
</author>
<date day="25" month="March" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-fgont-6man-rfc4941bis-00"/>
</reference>
</front> <reference anchor="draft-ietf-6man-default-iids-16" target="https://www.ietf.org
/archive/id/draft-ietf-6man-default-iids-16.txt">
<front>
<title>
Recommendation on Stable IPv6 Interface Identifiers
</title>
<author initials="F." surname="Gont" fullname="Fernando Gont"> </author>
<author initials="A." surname="Cooper" fullname="Alissa Cooper">
<organization>Cisco</organization>
</author>
<author initials="D." surname="Thaler" fullname="Dave Thaler">
<organization>Microsoft</organization>
</author>
<author initials="W." surname="LIU" fullname="Will (Shucheng) LIU">
<organization>Huawei Technologies</organization>
</author>
<date month="September" day="28" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-default-iids-16"/>
</reference>
<seriesInfo name='Internet-Draft' value='draft-ietf-ntp-refid-updates-00' <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"
/> />
<format type='TXT' <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7707.xml"
target='https://tools.ietf.org/id/draft-ietf-ntp-refid-updates-00 />
.txt' />
</reference>
<reference anchor="Gont-NTP" target="https://mailarchive.ietf.org/arch/ms <reference anchor="draft-gont-predictable-numeric-ids-03" target="https://datatr
g/ntp/NkfTHxUUOdp14Agh3h1IPqfcRRg"> acker.ietf.org/doc/html/draft-gont-predictable-numeric-ids-03">
<front> <front>
<title>[Ntp] Comments on draft-ietf-ntp-refid-updates-05< <title>
/title> Security and Privacy Implications of Numeric Identifiers Employed in Network Pro
<author initials="F." surname="Gont" fullname="Fernando G tocols
ont"> </title>
<organization></organization> <author initials="F." surname="Gont" fullname="Fernando Gont"> </author>
</author> <author initials="I." surname="Arce" fullname="Ivan Arce">
<date month="April" day="16" year="2019"/> <organization>Quarkslab</organization>
</front> </author>
<seriesInfo name="Post to the NTP WG mailing list" value= <date month="March" day="11" year="2019"/>
" Message-ID: &lt;d871d66d-4043-d8d0-f924-2191ebb2e2ce@si6networks.com&gt;"/> </front>
</reference> <seriesInfo name="Internet-Draft" value="draft-gont-predictable-numeric-ids-03"/
>
</reference>
<?rfc include="reference.I-D.ietf-ntp-refid-updates" ?> <reference anchor='RFC9416' target='https://www.rfc-editor.org/info/rfc9416'>
<front>
<title>Security Considerations for Transient Numeric Identifiers Employed in Net
work Protocols</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="BCP" value="72"/>
<seriesInfo name="RFC" value="9416"/>
<seriesInfo name="DOI" value="10.17487/RFC9416"/>
</reference>
<?rfc include="reference.RFC.5905" ?> <reference anchor='RFC9415' target='https://www.rfc-editor.org/info/rfc9415'>
<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>
<!-- md5 --> <reference anchor="draft-ietf-6man-rfc2460bis-05" target="https://www.ietf.org/a
<!-- rchive/id/draft-ietf-6man-rfc2460bis-05.txt">
<?rfc include="reference.RFC.1321" ?> <front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="Stephen E. Deering" initials="S." surname="Deering"/>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden"/>
<date day="28" month="June" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc2460bis-05"/>
</reference>
<!-- Pervasive Monitoring --> <reference anchor="draft-ietf-6man-rfc2460bis-13" target="https://www.ietf.org/a
<?rfc include="reference.RFC.7258" ?> rchive/id/draft-ietf-6man-rfc2460bis-13.txt">
<front>
<title>draft-ietf-6man-rfc2460bis-13</title>
<author fullname="Stephen E. Deering" initials="S." surname="Deering"/>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden"/>
<date day="19" month="May" year="2017"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc2460bis-13"/>
</reference>
<!-- TCP ISNs --> <reference anchor="draft-stenn-ntp-not-you-refid-00" target="https://www.ietf.or
g/archive/id/draft-stenn-ntp-not-you-refid-00.txt">
<front>
<title>Network Time Protocol Not You REFID</title>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
<organization>Boston University</organization>
</author>
<author fullname="Harlan Stenn" initials="H." surname="Stenn">
<organization>Network Time Foundation</organization>
</author>
<date day="8" month="July" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-stenn-ntp-not-you-refid-00"/>
</reference>
<?rfc include="reference.RFC.1948" ?> <reference anchor="draft-ietf-ntp-refid-updates-00" target="https://www.ietf.org
/archive/id/draft-ietf-ntp-refid-updates-00.txt">
<front>
<title>Network Time Protocol REFID Updates</title>
<author fullname="Harlan Stenn" initials="H." surname="Stenn"/>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg"/>
<date day="13" month="November" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ntp-refid-updates-00"/>
</reference>
<reference anchor="Wright1994"> <reference anchor="Gont-NTP" target="https://mailarchive.ietf.org/arch/m
<front> sg/ntp/NkfTHxUUOdp14Agh3h1IPqfcRRg">
<title>TCP/IP Illustrated, Volume 2: The Implementation</ <front>
title> <title>[Ntp] Comments on draft-ietf-ntp-refid-updates-05</title>
<author initials="G.R." surname="Wright" fullname= "Gary <author initials="F." surname="Gont" fullname="Fernando Gont">
R. Wright"> <organization/></author>
<organization></organization> <date day="16" month="April" year="2019"/>
</author> </front>
<refcontent>message to the IETF NTP mailing list</refcontent>
</reference>
<author initials="W.R." surname="Stevens" fullname= "W. R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"
ichard Stevens"> />
<organization></organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"
</author> />
<date year="Addison-Wesley, 1994"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1948.xml"
</front> />
<!-- The usage of the date element (above) avoids an extra space
before the comma.
<seriesInfo name="Addison-Wesley" value=""/>-->
</reference>
<!-- <reference anchor="Wright1994">
<reference anchor="CPNI-TCP" target="http://www.gont.com.ar/papers/tn-03- <front>
09-security-assessment-TCP.pdf"> <title>TCP/IP Illustrated, Volume 2: The Implementation</title>
<front> <author initials="G." surname="Wright" fullname="Gary R. Wright">
<title>Security Assessment of the Transmission Control Pr <organization/>
otocol (TCP)</title> </author>
<author initials="F." surname="Gont" fullname= "Fernando <author initials="W." surname="Stevens" fullname="W. Richard Stevens
Gont"> ">
<organization></organization> <organization/>
</author> </author>
<date year="2009"/> <date year="1995" month="February"/>
</front> </front>
<seriesInfo name="" value="United Kingdom's Centre for the Protec <refcontent>Addison-Wesley</refcontent>
tion of National Infrastructure (CPNI) Technical Report"/>
</reference> </reference>
<reference anchor="Zalewski2001" target="https://lcamtuf.coredump.cx/oldt cp/tcpseq.html"> <reference anchor="Zalewski2001" target="https://lcamtuf.coredump.cx/oldt cp/tcpseq.html">
<front> <front>
<title>Strange Attractors and TCP/IP Sequence Number Anal <title>Strange Attractors and TCP/IP Sequence Number Analysis (2001)
ysis</title> </title>
<author initials="M." surname="Zalewski" fullname="M. Zal <author initials="M." surname="Zalewski" fullname="M. Zalewski">
ewski"> <organization/>
<organization></organization> </author>
</author> <date year="2001" month="March"/>
<date year="2001"/> </front>
</front> </reference>
</reference>
<reference anchor="Zalewski2002" target="https://lcamtuf.coredump.cx/newt
cp/">
<front>
<title>Strange Attractors and TCP/IP Sequence Number Anal
ysis - One Year Later</title>
<author initials="M." surname="Zalewski" fullname="M. Zal
ewski">
<organization></organization>
</author>
<date year="2001"/>
</front>
</reference>
<reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb <reference anchor="Zalewski2002" target="https://lcamtuf.coredump.cx/new
/papers/ipext.pdf"> tcp/">
<front> <front>
<title>Security Problems in the TCP/IP Protocol Suite</ti <title>Strange Attractors and TCP/IP Sequence Number Analysis - One
tle> Year Later (2002)</title>
<author initials="S." surname="Bellovin" fullname="Bellov <author initials="M." surname="Zalewski" fullname="M. Zalewski">
in"> <organization/>
<organization></organization> </author>
</author> <date year="2002"/>
<date year="Computer Communications Review, vol. 19, no. </front>
2, pp. 32-48, 1989"/> </reference>
</front>
</reference>
<!-- <reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~sm
<reference anchor="Joncheray1995"> b/papers/ipext.pdf">
<front> <front>
<title>A Simple Active Attack Against TCP</title> <title>Security Problems in the TCP/IP Protocol Suite</title>
<author initials="L." surname="Joncheray" fullname="L. Jo <author initials="S." surname="Bellovin" fullname="S.M. Bellovin">
ncheray"> <organization/>
<organization></organization> </author>
</author> <date year="1989" month="April"/>
<date year="Proc. Fifth Usenix UNIX Security Symposium, 1 </front>
995"/> <refcontent>Computer Communications Review, vol. 19, no. 2, pp. 32-48</
</front> refcontent>
</reference> </reference>
<reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/pa pers/117.pdf"> <reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/pa pers/117.pdf">
<front> <front>
<title>A Weakness in the 4.2BSD UNIX TCP/IP Software</tit <title>A Weakness in the 4.2BSD UNIX TCP/IP Software</title>
le> <author initials="R." surname="Morris" fullname="Robert Morris">
<author initials="R." surname="Morris" fullname="Robert M <organization/>
orris"> </author>
<organization></organization> <date year="1985" month="February"/>
</author> </front>
<date year="1985"/> <refcontent>CSTR 117, AT&amp;T Bell Laboratories, Murray Hill, NJ</refc
</front> ontent>
<seriesInfo name="CSTR 117," value="AT&amp;T Bell Laboratories, M </reference>
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://resources.sei.cmu.edu/asset_
files/WhitePaper/2001_019_001_496192.pdf">
<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>
<reference anchor='I-D.eddy-rfc793bis-04'>
<front>
<title>Transmission Control Protocol Specification</title>
<author initials='W.' surname='Eddy' fullname='Wesley Eddy'>
<organization />
</author>
<date month='August' day='25' year='2014' />
<abstract><t>
This document specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the Internet
stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793.
This document obsoletes RFC 793 and several other RFCs (TODO: list
all actual RFCs when finished).
RFC EDITOR NOTE: If approved for publication as an RFC, this should
be marked additionally as "STD: 7" and replace RFC 793 in that role.</
t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-eddy-rfc793bis-04' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-eddy-rfc793bis-04.txt' />
</reference>
<reference anchor="OpenBSD-TCP-ISN-I" target="https://cvsweb.openbsd.org/
src/sys/netinet/tcp_subr.c?rev=1.6">
<front>
<title>Implementation of TCP ISN randomization based on r
andom increments</title>
<author>
<organization>OpenBSD</organization>
</author>
<date day="29" month="July" year="1996"/>
</front>
</reference>
<reference anchor="OpenBSD-TCP-ISN-R" target="https://cvsweb.openbsd.org/
src/sys/netinet/tcp_subr.c?rev=1.37">
<front>
<title>Implementation of TCP ISN randomization based on s
imple randomization</title>
<author>
<organization>OpenBSD</organization>
</author>
<date day="13" month="December" year="2000"/>
</front>
</reference>
<reference anchor="OpenBSD-TCP-ISN-H" target="https://cvsweb.openbsd.org/ <reference anchor="USCERT2001" target="https://www.kb.cert.org/vuls/id/4
src/sys/netinet/tcp_subr.c?rev=1.97"> 98440">
<front> <front>
<title>Implementation of RFC1948 for TCP ISN randomizatio <title>Multiple TCP/IP implementations may use statistically predict
n</title> able initial sequence numbers</title>
<author> <author>
<organization>OpenBSD</organization> <organization>CERT CC</organization>
</author> </author>
<date day="13" month="December" year="2000"/> <date year="2001" month="March"/>
</front> </front>
</reference> <refcontent>Vulnerability Note VU#498440</refcontent>
</reference>
<!-- NTP Port Randomization --> <reference anchor="CERT2001" target="https://resources.sei.cmu.edu/asset
_files/WhitePaper/2001_019_001_496192.pdf">
<front>
<title>CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP In
itial Sequence Numbers</title>
<author>
<organization>CERT/CC</organization>
</author>
<date year="2001" month="May"/>
</front>
</reference>
<?rfc include="reference.I-D.gont-ntp-port-randomization" ?> <reference anchor="Shimomura1995" target="https://www.gont.com.ar/files/
<?rfc include="reference.I-D.ietf-ntp-port-randomization" ?> post-shimomura-usenet.txt">
<?rfc include="reference.RFC.9109" ?> <front>
<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</refcont
ent>
</reference>
<reference anchor="NTP-PORTR" target="https://mailarchive.ietf.org/arch/b <reference anchor="draft-eddy-rfc793bis-04" target="https://www.ietf.org
rowse/ntp/?gbt=1&amp;index=n09Sb61WkH03lSRtamkELXwEQN4"> /archive/id/draft-eddy-rfc793bis-04.txt">
<front> <front>
<title>[Ntp] New rev of the NTP port randomization I-D (F <title>Transmission Control Protocol Specification</title>
wd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)</titl <author fullname="Wesley Eddy" initials="W." surname="Eddy" role="editor"/>
e> <date day="25" month="August" year="2014"/>
<author fullname="Fernando Gont" initials="F." surname="Gont"> </front>
<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks / UTN-FRH</orga <seriesInfo name="Internet-Draft" value="draft-eddy-rfc793bis-04"/>
nization> </reference>
<address> <reference anchor="OpenBSD-TCP-ISN-I" target="https://cvsweb.openbsd.org
<postal> /src/sys/netinet/tcp_subr.c?rev=1.6">
<street>Evaristo Carriego 2644</street> <front>
<code>1706</code> <title>Implementation of TCP ISN randomization based on random incre
<city>Haedo</city> ments</title>
<region>Provincia de Buenos Aires</region> <author>
<country>Argentina</country> <organization>OpenBSD</organization>
</postal> </author>
<date month="July" year="1996"/>
</front>
</reference>
<phone>+54 11 4650 8472</phone> <reference anchor="OpenBSD-TCP-ISN-R" target="https://cvsweb.openbsd.org
<email>fgont@si6networks.com</email> /src/sys/netinet/tcp_subr.c?rev=1.37">
<uri>https://www.si6networks.com</uri> <front>
<title>Implementation of TCP ISN randomization based on simple rando
mization</title>
<author>
<organization>OpenBSD</organization>
</author>
<date month="December" year="2000"/>
</front>
</reference>
</address> <reference anchor="OpenBSD-TCP-ISN-H" target="https://cvsweb.openbsd.org
</author> /src/sys/netinet/tcp_subr.c?rev=1.97">
<date year="2019"/> <front>
</front> <title>Implementation of RFC1948 for TCP ISN randomization</title>
<author>
<organization>OpenBSD</organization>
</author>
<date month="June" year="2007"/>
</front>
</reference>
</reference> <reference anchor="draft-gont-ntp-port-randomization-00" target="https://www.iet
f.org/archive/id/draft-gont-ntp-port-randomization-00.txt">
<front>
<title>Port Randomization in the Network Time Protocol Version 4</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Guillermo Gont" initials="G." surname="Gont"/>
<date day="16" month="April" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-ntp-port-randomization-00"
/>
</reference>
<reference anchor="NIST-NTP" target="https://tf.nist.gov/general/pdf/2818 <reference anchor="draft-ietf-ntp-port-randomization-00" target="https://www.iet
.pdf"> f.org/archive/id/draft-ietf-ntp-port-randomization-00.txt">
<front> <front>
<title>Usage Analysis of the NIST Internet Time Service</ <title>Port Randomization in the Network Time Protocol Version 4</title>
title> <author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Guillermo Gont" initials="G." surname="Gont"/>
<author fullname="Miroslav Lichvar" initials="M." surname="Lichvar"/>
<date day="22" month="October" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ntp-port-randomization-00"
/>
</reference>
<author initials="J.A." surname="Sherman" fullname="Jeff <reference anchor="draft-ietf-ntp-port-randomization-08" target="https://www.iet
A. Sherman"> f.org/archive/id/draft-ietf-ntp-port-randomization-08.txt">
<organization></organization> <front>
</author> <title>Port Randomization in the Network Time Protocol Version 4</title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<author fullname="Guillermo Gont" initials="G." surname="Gont"/>
<author fullname="Miroslav Lichvar" initials="M." surname="Lichvar"/>
<date day="10" month="June" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ntp-port-randomization-00"
/>
</reference>
<author initials="J." surname="Levine" fullname="Judah Le <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9109.xml"
vine"> />
<organization></organization>
</author>
<date year="2016" month="March" day="8"/>
</front>
<seriesInfo name="Journal of Research of the National Institute o
f Standards and Technology" value="Volume 121" />
</reference>
<reference anchor="IPID-DEV" target="https://arxiv.org/pdf/1906.10478.pdf <reference anchor="NTP-PORTR" target="https://mailarchive.ietf.org/arch/
"> msg/ntp/xSCu5Vhb3zoWcqEjUMmzP8pOdW4/">
<front> <front>
<title>From IP ID to Device ID and KASLR Bypass (Extended <title>[Ntp] New rev of the NTP port randomization I-D (Fwd: New Ver
Version)</title> sion Notification for draft-gont-ntp-port-randomization-01.txt)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date day="21" month="May" year="2019"/>
</front>
<refcontent>message to the IETF NTP mailing list</refcontent>
</reference>
<author initials="A." surname="Klein" fullname="Amit Klei <reference anchor="NIST-NTP" target="https://tf.nist.gov/general/pdf/281
n"> 8.pdf">
<organization></organization> <front>
</author> <title>Usage Analysis of the NIST Internet Time Service</title>
<author initials="J." surname="Sherman" fullname="Jeff A. Sherman">
<organization/>
</author>
<author initials="J." surname="Levine" fullname="Judah Levine">
<organization/>
</author>
<date year="2016" month="March"/>
</front>
<refcontent>Journal of Research of the National Institute of Standards
and Technology, Volume 121</refcontent>
</reference>
<author initials="B." surname="Pinkas" fullname="Benny Pi <reference anchor="IPID-DEV" target="https://arxiv.org/pdf/1906.10478.pd
nkas"> f">
<organization></organization> <front>
</author> <title>From IP ID to Device ID and KASLR Bypass (Extended Version)</
<date year="2019" month="June"/> title>
</front> <author initials="A." surname="Klein" fullname="Amit Klein">
<!-- <organization/>
<seriesInfo name="Journal of Research of the National Institute o </author>
f Standards and Technology" value="Volume 121" /> <author initials="B." surname="Pinkas" fullname="Benny Pinkas">
<organization/>
</author>
<date year="2019" month="October"/>
</front>
<seriesInfo name="DOI" value="10.48550/arXiv.1906.10478"/>
</reference> </reference>
<!-- ICMP attacks <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"
<?rfc include="reference.RFC.5927" ?> />
--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6274.xml"
/>
<!-- IPv6 Flow Label <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7739.xml"
<?rfc include="reference.I-D.gont-6man-flowlabel-security" ?> />
<?rfc include="reference.RFC.7098" ?>
<!-- DNS -->
<?rfc include="reference.RFC.1035" ?>
<!-- Fragment ID -->
<!-- IPv4 security -->
<?rfc include="reference.RFC.6274" ?>
<?rfc include="reference.RFC.7739" ?>
<!-- <?rfc include="reference.RFC.4963" ?> --> <!-- IPv4 Reassembly Errors at
High Data Rates -->
<reference anchor="Bellovin2002" target="https://www.cs.columbia.edu/~smb /papers/fnat.pdf"> <reference anchor="Bellovin2002" target="https://www.cs.columbia.edu/~smb /papers/fnat.pdf">
<front> <front>
<title>A Technique for Counting NATted Hosts</title> <title>A Technique for Counting NATted Hosts</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 year="2002" month="November"/>
</front> </front>
<seriesInfo name="IMW'02" value="Nov. 6-8, 2002, Marseille, Franc <refcontent>IMW'02, Marseille, France</refcontent>
e"/> <seriesInfo name="DOI" value="10.1145/637201.637243"/>
</reference> </reference>
<reference anchor="Fyodor2002" target="http://www.insecure.org/nmap/idles
can.html">
<front>
<title>Idle scanning and related IP ID games</title>
<author initials="" surname="Fyodor" fullname= "Fyodor">
<organization></organization>
</author>
<date year="2002"/>
</front>
</reference>
<reference anchor="Sanfilippo1998a" target="http://seclists.org/bugtraq/1
998/Dec/48">
<front>
<title>about the ip header id</title>
<author initials="S." surname="Sanfilippo" fullname="S. S
anfilippo">
<organization></organization>
</author>
<date/>
</front>
<seriesInfo name="Post to Bugtraq mailing-list," value="Mon Dec 1
4 1998" />
</reference>
<reference anchor="Sanfilippo1998b" target="https://github.com/antirez/hp
ing/raw/master/docs/SPOOFED_SCAN.txt">
<front>
<title>Idle scan</title>
<author initials="S." surname="Sanfilippo" fullname="S. S
anfilippo">
<organization></organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="Post to Bugtraq" value="mailing-list" />
</reference>
<reference anchor="Sanfilippo1999" target="https://github.com/antirez/hpi
ng/raw/master/docs/MORE-FUN-WITH-IPID">
<front>
<title>more ip id</title>
<author initials="S." surname="Sanfilippo" fullname="S. S
anfilippo">
<organization></organization>
</author>
<date year="1999"/>
</front>
<seriesInfo name="Post to Bugtraq" value="mailing-list" />
</reference>
<reference anchor="Morbitzer2013" target="https://seclists.org/nmap-dev/2
013/q2/394">
<front>
<title>[PATCH] TCP Idle Scan in IPv6</title>
<author initials="M." surname="Morbitzer" fullname= "Math
ias Morbitzer">
<organization></organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="" value="Message posted to the nmap-dev mailing
-list"/>
</reference>
<reference anchor="OpenBSD-IPv4-ID" target="https://cvsweb.openbsd.org/sr
c/sys/netinet/ip_id.c?rev=1.1">
<front>
<title>Randomization of the IPv4 Identification field</ti
tle>
<author>
<organization>OpenBSD</organization>
</author>
<date day="26" month="December" year="1998"/>
</front>
</reference>
<reference anchor="OpenBSD-IPv6-ID" target="https://cvsweb.openbsd.org/sr
c/sys/netinet6/ip6_id.c?rev=1.1">
<front>
<title>Randomization of the IPv6 Identification field</ti
tle>
<author>
<organization>OpenBSD</organization>
</author>
<date day="1" month="October" year="2003"/>
</front>
</reference>
<reference anchor="Silbersack2005" target="https://citeseerx.ist.psu.edu/
viewdoc/download?doi=10.1.1.91.4542&amp;rep=rep1&amp;type=pdf">
<front>
<title>Improving TCP/IP security through randomization wi
thout sacrificing interoperability</title>
<author initials="M.J." surname="Silbersack" fullname="Mi
chael James Silbersack">
<organization>The FreeBSD Project</organization>
</author>
<date year="2005"/>
</front>
<seriesInfo name="EuroBSDCon 2005" value="Conference"/>
</reference>
<reference anchor="Zalewski2003" target="https://lcamtuf.coredump.cx/ipfr
ag.txt">
<front>
<title>A new TCP/IP blind data injection technique?</titl
e>
<author initials="M." surname="Zalewski" fullname="M. Zal
ewski">
<organization></organization>
</author>
<date year="2003"/>
</front>
</reference>
<reference anchor="Arce1997" target="http://www.openbsd.org/advisories/sn
i_12_resolverid.txt">
<front>
<title>BIND Vulnerabilities and Solutions</title>
<author initials="I." surname="Arce" fullname="Ivan Arce"
>
<organization>Core Seguridad del Informacion</org
anization>
</author>
<author initials="E." surname="Kargieman" fullname="Emili
ano Kargieman">
<organization>Core Seguridad del Informacion</org
anization>
</author>
<date year="1997"/>
</front>
</reference>
<reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/
papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf">
<front>
<title>OpenBSD DNS Cache Poisoning and Multiple O/S Predi
ctable IP ID Vulnerability</title>
<author initials="A." surname="Klein" fullname="Amit Klei
n">
<organization></organization>
</author>
<date year="2007"/>
</front>
</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="RedHat2011" target="https://rhn.redhat.com/errata/RHSA
-2011-1465.html">
<front>
<title>RedHat Security Advisory RHSA-2011:1465-1: Importa
nt: kernel security and bug fix update</title>
<author initials="" surname="RedHat" fullname="RedHat">
<organization></organization>
</author>
<date year="2011"/>
</front>
<!-- <seriesInfo name="Hack In Paris 2011 Conf
erence" value="Paris, France"/> -->
</reference>
<reference anchor="Ubuntu2011" target="https://ubuntu.com/security/notice
s/USN-1253-1">
<front>
<title>Ubuntu: USN-1253-1: Linux kernel vulnerabilities</
title>
<author initials="" surname="Ubuntu" fullname="Ubuntu">
<organization></organization>
</author>
<date year="2011"/>
</front>
<!-- <seriesInfo name="Hack In Paris 2011 Conf
erence" value="Paris, France"/> -->
</reference>
<reference anchor="SUSE2011" target="https://lists.opensuse.org/opensuse-
security-announce/2011-12/msg00011.html">
<front>
<title>SUSE Security Announcement: Linux kernel security
update (SUSE-SA:2011:046)</title>
<author initials="" surname="SUSE" fullname="SUSE">
<organization></organization>
</author>
<date year="2011"/>
</front>
<!-- <seriesInfo name="Hack In Paris 2011 Conf
erence" value="Paris, France"/> -->
</reference>
<reference anchor="Gont2012" target="https://www.si6networks.com/files/pr
esentations/bsdcan2012/fgont-bsdcan2012-recent-advances-in-ipv6-security.pdf">
<front>
<title>Recent Advances in IPv6 Security</title>
<author initials="F." surname="Gont" fullname="Fernando G
ont">
<organization></organization>
</author>
<date month="May" year="2012"/>
</front>
<seriesInfo name="BSDCan 2012 Conference" value="Ottawa,
Canada. May 11-12, 2012"/>
</reference>
<?rfc include="reference.I-D.gont-6man-predictable-fragment-id" ?> <reference anchor="Fyodor2002" target="https://nmap.org/presentations/Ca
<?rfc include="reference.I-D.ietf-6man-predictable-fragment-id" ?> nSecWest03/CD_Content/idlescan_paper/idlescan.html">
<front>
<title>Idle scanning and related IP ID games</title>
<author>
<organization>Fyodor</organization>
</author>
<date year="2002" month="September"/>
</front>
</reference>
<reference anchor='draft-ietf-6man-predictable-fragment-id-01'> <reference anchor="Sanfilippo1998a" target="http://seclists.org/bugtraq/
<front> 1998/Dec/48">
<title>Security Implications of Predictable Fragment Identification Value <front>
s</title> <title>about the ip header id</title>
<author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfi
lippo">
<organization/>
</author>
<date day="14" month="December" year="1998"/>
</front>
<refcontent>message to the Bugtraq mailing list</refcontent>
</reference>
<author initials='F.' surname='Gont' fullname='Fernando Gont'> <reference anchor="Sanfilippo1998b" target="https://seclists.org/bugtraq
<organization /> /1998/Dec/79">
</author> <front>
<title>new tcp scan method</title>
<author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfi
lippo">
<organization/>
</author>
<date year="1998" month="December" day="18"/>
</front>
<refcontent>message to the Bugtraq mailing list</refcontent>
</reference>
<date month='April' day='30' year='2014' /> <reference anchor="Sanfilippo1999" target="https://github.com/antirez/hp
ing/raw/master/docs/MORE-FUN-WITH-IPID">
<front>
<title>more ip id</title>
<author initials="S." surname="Sanfilippo" fullname="S. Sanfilippo">
<organization/>
</author>
<date year="1999" month="November"/>
</front>
<refcontent>message to the Bugtraq mailing list</refcontent>
</reference>
</front> <reference anchor="Morbitzer2013" target="https://seclists.org/nmap-dev/
2013/q2/394">
<front>
<title>[PATCH] TCP Idle Scan in IPv6</title>
<author initials="M." surname="Morbitzer" fullname="Mathias Morbitze
r">
<organization/>
</author>
<date day="3" year="2013" month="June"/>
</front>
<refcontent>message to the nmap-dev mailing list</refcontent>
</reference>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-predictable-frag <reference anchor="OpenBSD-IPv4-ID" target="https://cvsweb.openbsd.org/s
ment-id-01' /> rc/sys/netinet/ip_id.c?rev=1.1">
<front>
<title>Randomization of the IPv4 Identification field</title>
<author>
<organization>OpenBSD</organization>
</author>
<date month="December" year="1998"/>
</front>
</reference>
<format type='TXT' <reference anchor="OpenBSD-IPv6-ID" target="https://cvsweb.openbsd.org/s
target='https://tools.ietf.org/id/draft-ietf-6man-predictable-fra rc/sys/netinet6/ip6_id.c?rev=1.1">
gment-id-01.txt' /> <front>
</reference> <title>Randomization of the IPv6 Identification field</title>
<author>
<organization>OpenBSD</organization>
</author>
<date month="October" year="2003"/>
</front>
</reference>
<reference anchor='draft-ietf-6man-predictable-fragment-id-02'> <reference anchor="Silbersack2005" target="https://citeseerx.ist.psu.edu
<front> /viewdoc/download?doi=10.1.1.91.4542&amp;rep=rep1&amp;type=pdf">
<title>Security Implications of Predictable Fragment Identification Value <front>
s</title> <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>
<author initials='F.' surname='Gont' fullname='Fernando Gont'> <reference anchor="Zalewski2003" target="https://lcamtuf.coredump.cx/ipf
<organization /> rag.txt">
</author> <front>
<title>A new TCP/IP blind data injection technique?</title>
<author initials="M." surname="Zalewski" fullname="Michal Zalewski">
<organization/>
</author>
<date year="2003" month="December"/>
</front>
</reference>
<date month='December' day='19' year='2014' /> <reference anchor="Arce1997" target="http://www.openbsd.org/advisories/s
ni_12_resolverid.txt">
<front>
<title>BIND Vulnerabilities and Solutions</title>
<author initials="I." surname="Arce" fullname="Ivan Arce">
<organization>Core Seguridad del Informacion</organization>
</author>
<author initials="E." surname="Kargieman" fullname="Emiliano Kargiem
an">
<organization>Core Seguridad del Informacion</organization>
</author>
<date year="1997" month="April"/>
</front>
</reference>
</front> <reference anchor="Klein2007" target="https://dl.packetstormsecurity.net
/papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vul
nerability.pdf">
<front>
<title>OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP I
D Vulnerability</title>
<author initials="A." surname="Klein" fullname="Amit Klein">
<organization/>
</author>
<date year="2007" month="October"/>
</front>
</reference>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-predictable-frag <reference anchor="Gont2011" target="https://www.si6networks.com/files/p
ment-id-02' /> resentations/hip2011/fgont-hip2011-hacking-ipv6-networks.pdf">
<front>
<title>Hacking IPv6 Networks (training course)</title>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<organization/>
</author>
<date month="June" year="2011"/>
</front>
<refcontent>Hack In Paris 2011 Conference, Paris, France</refcontent>
</reference>
<format type='TXT' <reference anchor="RedHat2011" target="https://rhn.redhat.com/errata/RHS
target='https://tools.ietf.org/id/draft-ietf-6man-predictable-fra A-2011-1465.html">
gment-id-02.txt' /> <front>
<title>RHSA-2011:1465-1 - Security Advisory</title>
<author>
<organization>Red Hat</organization>
</author>
<date year="2011" month="November"/>
</front>
</reference> </reference>
<reference anchor='draft-gont-6man-predictable-fragment-id-00'> <reference anchor="Ubuntu2011" target="https://ubuntu.com/security/notic
<front> es/USN-1253-1">
<title>Security Implications of Predictable Fragment Identification Value <front>
s</title> <title>USN-1253-1: Linux kernel vulnerabilities</title>
<author>
<author initials='F.' surname='Gont' fullname='Fernando Gont'> <organization>Ubuntu</organization>
<organization /> </author>
</author> <date year="2011" month="November"/>
</front>
<date month='December' day='15' year='2011' />
<abstract><t>IPv6 specifies the Fragment Header, which is employed for th
e
fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the IPv6
Source Address and the IPv6 Destination Address of the packet,
identifies fragments that correspond to the same original datagram,
such that they can be reassembled together at the receiving host.
The only requirement for setting the "Identification" value is that
it must be different than that of any other fragmented packet sent
recently with the same Source Address and Destination Address. Some
implementations simply use a global counter for setting the Fragment
Identification field, thus leading to predictable values. This
document analyzes the security implications of predictable
Identification values, and updates RFC 2460 specifying additional
requirements for setting the Fragment Identification, such that the
aforementioned security implications are mitigated.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-predictable-frag
ment-id-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-predictable-fra
gment-id-00.txt' />
</reference> </reference>
<reference anchor='draft-ietf-6man-predictable-fragment-id-00'> <reference anchor="SUSE2011" target="https://lists.opensuse.org/opensuse
<front> -security-announce/2011-12/msg00011.html">
<title>Security Implications of Predictable Fragment Identification Value <front>
s</title> <title>[security-announce] SUSE Security Announcement: Linux kernel
security update (SUSE-SA:2011:046)</title>
<author initials='F.' surname='Gont' fullname='Fernando Gont'> <author initials="M." surname="Meissner" fullname="Marcus Meissner">
<organization /> <organization>SUSE</organization>
</author> </author>
<date day="13" year="2011" month="December"/>
<date month='March' day='22' year='2013' /> </front>
<refcontent>message to the openSUSE Security Announce mailing list</ref
</front> content>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-predictable-frag
ment-id-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-predictable-fra
gment-id-00.txt' />
</reference> </reference>
<reference anchor='draft-ietf-6man-predictable-fragment-id-08'> <reference anchor="Gont2012" target="https://www.si6networks.com/files/p
<front> resentations/bsdcan2012/fgont-bsdcan2012-recent-advances-in-ipv6-security.pdf">
<title>Security Implications of Predictable Fragment Identification Value <front>
s</title> <title>Recent Advances in IPv6 Security</title>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<author initials='F.' surname='Gont' fullname='Fernando Gont'> <organization/></author>
<organization /> <date month="May" year="2012"/>
</author> </front>
<refcontent>BSDCan 2012 Conference, Ottawa, Canada</refcontent>
<date month='June' day='9' year='2015' /> </reference>
<abstract><t>IPv6 specifies the Fragment Header, which is employed for th
e
fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the IPv6
Source Address and the IPv6 Destination Address of a packet,
identifies fragments that correspond to the same original datagram,
such that they can be reassembled together by the receiving host.
The only requirement for setting the "Identification" field is that
the corresponding value must be different than that employed for any
other fragmented packet sent recently with the same Source Address
and Destination Address. Some implementations use a simple global
counter for setting the Identification field, thus leading to
predictable Identification values. This document analyzes the
security implications of predictable Identification values, and
provides implementation guidance for selecting the Identification
field of the Fragment Header, such that the aforementioned security
implications are mitigated.</t></abstract>
</front> <reference anchor="draft-gont-6man-predictable-fragment-id-03" target="https://w
ww.ietf.org/archive/id/draft-gont-6man-predictable-fragment-id-03.txt">
<front>
<title>Security Implications of Predictable Fragment Identification Values</
title>
<author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="9" month="January" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gont-6man-predictable-fragment-
id-03"/>
</reference>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-predictable-frag <reference anchor="draft-ietf-6man-predictable-fragment-id-10" target="https://w
ment-id-08' /> ww.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-10.txt">
<format type='TXT' <front>
target='https://tools.ietf.org/id/draft-ietf-6man-predictable-fra <title>Security Implications of Predictable Fragment Identification Values</
gment-id-08.txt' /> title>
</reference> <author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="9" month="October" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-
id-10"/>
</reference>
<!-- <reference anchor="draft-ietf-6man-predictable-fragment-id-01" target="https://w
<reference anchor='I-D.hinden-6man-rfc2460bis-07'> ww.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-01.txt">
<front> <front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title> <title>
Security Implications of Predictable Fragment Identification Values
<author initials='S.E.' surname='Deering' fullname='Stephen E. Deering'> </title>
<author initials='R.M.' surname='Hinden' fullname='Robert M. Hinden'> <author fullname="Fernando Gont" initials="F." surname="Gont"/>
<date day="29" month="April" year="2014"/>
<organization />
</author>
<date month='June' day='9' year='2015' />
<abstract><t> This document specifies version 6 of the Internet Protocol (IPv6
),
also sometimes referred to as IP Next Generation or IPng. It
obsoletes RFC2460.</t></abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-rfc2460bis-02' /> -01"/>
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-0
2.txt' />
</reference> </reference>
<reference anchor="draft-ietf-6man-predictable-fragment-id-02" target="h
<!-- http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf --> ttps://datatracker.ietf.org/doc/html/draft-ietf-6man-predictable-fragment-id-02"
>
<!-- DNS --> <front>
<title>Security Implications of Predictable Fragment Identification
Values</title>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<organization/></author>
<date month="December" day="19" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-f
ragment-id-02"/>
</reference>
<reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/c <reference anchor="draft-gont-6man-predictable-fragment-id-00" target="https://w
hristoph-schuba/schuba-DNS-msthesis.pdf"> ww.ietf.org/archive/id/draft-gont-6man-predictable-fragment-id-00.txt">
<front> <front>
<title>ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PR <title>
OTOCOL</title> Security Implications of Predictable Fragment Identification Values
<author initials="C." surname="Schuba" fullname="Christop </title>
h Schuba"> <author fullname="Fernando Gont" initials="F." surname="Gont"/>
<organization></organization> <date day="15" month="December" year="2011"/>
</author> </front>
<date year="1993"/> <seriesInfo name="Internet-Draft" value="draft-gont-6man-predictable-fragment-id
</front> -00"/>
</reference> </reference>
<reference anchor="Vixie1995" target="https://www.usenix.org/legacy/publi <reference anchor="draft-ietf-6man-predictable-fragment-id-00" target="https://w
cations/library/proceedings/security95/full_papers/vixie.pdf"> ww.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-00.txt">
<front> <front>
<title>DNS and BIND Security Issues</title> <title>
<author initials="P." surname="Vixie" fullname="Paul Vixi Security Implications of Predictable Fragment Identification Values
e"> </title>
<organization></organization> <author fullname="Fernando Gont" initials="F." surname="Gont"/>
</author> <date day="22" month="March" year="2013"/>
<date month="May" day="2" year="1995"/> </front>
</front> <seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id
<seriesInfo name="5th Usenix Security Symposium" value="M -00"/>
ay 2, 1995"/> </reference>
</reference>
<reference anchor="Klein2007b" target="https://citeseerx.ist.psu.edu/view
doc/summary?doi=10.1.1.86.4474">
<front>
<title>BIND 9 DNS Cache Poisoning</title>
<author initials="A." surname="Klein" fullname="Amit Klei
n">
<organization></organization>
</author>
<date month="March" year="2007"/>
</front>
</reference>
<reference anchor="Klein2007c" target="https://dl.packetstormsecu
rity.net/papers/attack/Windows_DNS_Cache_Poisoning.pdf">
<front>
<title>Windows DNS Server Cache Poisoning</title>
<author initials="A." surname="Klein" fullname="Amit Klei
n">
<organization></organization>
</author>
<date month="March" year="2007"/>
</front>
</reference>
<reference anchor="Sacramento2002" target="https://seclists.org/bugtraq/2 <reference anchor="draft-ietf-6man-predictable-fragment-id-08" target="https://w
002/Nov/331"> ww.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-08.txt">
<front> <front>
<title>CAIS-ALERT: Vulnerability in the sending requests <title>
control of BIND</title> Security Implications of Predictable Fragment Identification Values
<author initials="V." surname="Sacramento " fullname="Vag </title>
ner Sacramento "> <author fullname="Fernando Gont" initials="F." surname="Gont"/>
<organization></organization> <date day="9" month="June" year="2015"/>
</author> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id
-08"/>
</reference>
<date month="November" day="19" year="2002"/> <reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/c
</front> hristoph-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> <reference anchor="Vixie1995" target="https://www.usenix.org/legacy/publ
ications/library/proceedings/security95/full_papers/vixie.pdf">
<front>
<title>DNS and BIND Security Issues</title>
<author initials="P." surname="Vixie" fullname="Paul Vixie">
<organization/>
</author>
<date month="June" year="1995"/>
</front>
<refcontent>5th Usenix Security Symposium</refcontent>
</reference>
<reference anchor="Kaminsky2008" target="https://www.blackhat.com/present <reference anchor="Klein2007b" target="https://citeseerx.ist.psu.edu/doc
ations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf" /10.1.1.86.4474">
> <front>
<front> <title>BIND 9 DNS Cache Poisoning</title>
<title>Black Ops 2008: It's The End Of The Cache As We Kn <author initials="A." surname="Klein" fullname="Amit Klein">
ow It</title> <organization/>
<author initials="D." surname="Kaminsky " fullname="Dan K </author>
aminsky "> <date month="March" year="2007"/>
<organization></organization> </front>
</author> </reference>
<date month="August" year="2008"/> <reference anchor="Klein2007c" target="https://dl.packetstormsecurity.ne
</front> t/papers/attack/Windows_DNS_Cache_Poisoning.pdf">
<front>
<title>Windows DNS Server Cache Poisoning</title>
<author initials="A." surname="Klein" fullname="Amit Klein">
<organization/>
</author>
<date month="March" year="2007"/>
</front>
</reference>
</reference> <reference anchor="Sacramento2002" target="https://seclists.org/bugtraq/
2002/Nov/331">
<front>
<title>CAIS-ALERT: Vulnerability in the sending requests control of
BIND</title>
<author initials="V." surname="Sacramento " fullname="Vagner Sacrame
nto ">
<organization/>
</author>
<date day="25" month="November" year="2002"/>
</front>
<refcontent>message to the Bugtraq mailing list</refcontent>
</reference>
<reference anchor="Economou2010" target="https://www.coresecurity.com/cor <reference anchor="Kaminsky2008" target="https://www.blackhat.com/presen
e-labs/advisories/core-2010-0424-windows-smtp-dns-query-id-bugs"> tations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf
<front> ">
<title>Windows SMTP Service DNS query Id vulnerabilities< <front>
/title> <title>Black Ops 2008: It's The End Of The Cache As We Know It</titl
<author initials="N." surname="Economou" fullname="Nicola e>
s Economou"> <author initials="D." surname="Kaminsky " fullname="Dan Kaminsky ">
<organization></organization> <organization/>
</author> </author>
<date month="August" year="2008"/>
</front>
</reference>
<date month="May" day="4" year="2010"/> <reference anchor="Economou2010" target="https://www.coresecurity.com/co
</front> re-labs/advisories/core-2010-0424-windows-smtp-dns-query-id-bugs">
<seriesInfo name="Advisory ID Internal CORE-2010-0427" va <front>
lue="May 4, 2010"/> <title>Windows SMTP Service DNS query Id vulnerabilities</title>
</reference> <author initials="N." surname="Economou" fullname="Nicolas Economou"
>
<organization/>
</author>
<date month="May" year="2010"/>
</front>
<refcontent>Advisory ID Internal CORE-2010-0427</refcontent>
</reference>
</references> <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>
</references>
</references>
<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="Dave Crocker"/>, <contact fullname="Spe
ncer Dawkins"/>, <contact fullname="Theo de Raadt"/>, <contact fullname="Sara Di
ckinson"/>, <contact fullname="Guillermo Gont"/>, <contact fullname="Christian H
uitema"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Vincent Roca"
/>, <contact fullname="Kris Shrishak"/>, <contact fullname="Joe Touch"/>, <conta
ct fullname="Brian Trammell"/>, and <contact fullname="Christopher Wood"/> for p
roviding valuable comments on earlier versions of this document.</t>
<t>The authors would like to thank (in alphabetical order) <contact fullna
me="Steven Bellovin"/>, <contact fullname="Joseph Lorenzo Hall"/>, <contact full
name="Gre Norcie"/>, and <contact fullname="Martin Thomson"/> for providing valu
able comments on <xref target="draft-gont-predictable-numeric-ids-03" format="de
fault"/>, on which this document is based.</t>
<t><xref target="tcp-isns" format="default"/> of this document borrows tex
t from <xref target="RFC6528" format="default"/>, authored by <contact fullname=
"Fernando Gont"/> and <contact fullname="Steven Bellovin"/>.</t>
<t>The authors would like to thank <contact fullname="Sara Dickinson"/> an
d <contact fullname="Christopher Wood"/> for their guidance during the publicati
on process of this document.</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. 146 change blocks. 
2185 lines changed or deleted 1970 lines changed or added

This html diff was produced by rfcdiff 1.48.