rfc9414.original   rfc9414.txt 
Internet Research Task Force (IRTF) F. Gont Internet Research Task Force (IRTF) F. Gont
Internet-Draft SI6 Networks Request for Comments: 9414 SI6 Networks
Intended status: Informational I. Arce Category: Informational I. Arce
Expires: 14 June 2023 Quarkslab ISSN: 2070-1721 Quarkslab
11 December 2022 July 2023
Unfortunate History of Transient Numeric Identifiers Unfortunate History of Transient Numeric Identifiers
draft-irtf-pearg-numeric-ids-history-11
Abstract Abstract
This document analyzes the timeline of the specification and This document analyzes the timeline of the specification and
implementation of different types of "transient numeric identifiers" implementation of different types of "transient numeric identifiers"
used in IETF protocols, and how the security and privacy properties used in IETF protocols and how the security and privacy properties of
of such protocols have been affected as a result of it. It provides such protocols have been affected as a result of it. It provides
empirical evidence that advice in this area is warranted. This empirical evidence that advice in this area is warranted. This
document is a product of the Privacy Enhancement and Assessment document is a product of the Privacy Enhancements and Assessments
Research Group (PEARG) in the IRTF. Research Group (PEARG) in the IRTF.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Privacy
Enhancements and Assessments Research Group of the Internet Research
Task Force (IRTF). Documents approved for publication by the IRSG
are not candidates for any level of Internet Standard; see Section 2
of RFC 7841.
This Internet-Draft will expire on 14 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9414.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Threat Model
4. Issues with the Specification of Transient Numeric 4. Issues with the Specification of Transient Numeric Identifiers
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. IPv4/IPv6 Identification
4.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 6 4.2. TCP Initial Sequence Numbers (ISNs)
4.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 10 4.3. IPv6 Interface Identifiers (IIDs)
4.3. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . 12 4.4. NTP Reference IDs (REFIDs)
4.4. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . 15 4.5. Transport-Protocol Ephemeral Port Numbers
4.5. Transport Protocol Ephemeral Port Numbers . . . . . . . . 16 4.6. DNS ID
4.6. DNS Query ID . . . . . . . . . . . . . . . . . . . . . . 17 5. Conclusions
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. References
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 Acknowledgements
9.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Networking protocols employ a variety of transient numeric Networking protocols employ a variety of transient numeric
identifiers for different protocol objects, such as IPv4 and IPv6 identifiers for different protocol objects, such as IPv4 and IPv6
Fragment Identifiers [RFC0791] [RFC8200], IPv6 Interface Identifiers Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers
(IIDs) [RFC4291], transport protocol ephemeral port numbers (IIDs) [RFC4291], transport-protocol ephemeral port numbers
[RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], NTP [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC9293], NTP
Reference IDs (REFIDs) [RFC5905], and DNS Query IDs [RFC1035]. These Reference IDs (REFIDs) [RFC5905], and DNS IDs [RFC1035]. These
identifiers typically have specific interoperability requirements identifiers typically have specific requirements (e.g., uniqueness
(e.g. uniqueness during a specified period of time), and associated during a specified period of time) that must be satisfied such that
failure severities when such requirements are not met they do not result in negative interoperability implications and an
[I-D.irtf-pearg-numeric-ids-generation]. associated failure severity when such requirements are not met
[RFC9415].
For more than 30 years, a large number of implementations of the IETF | NOTE: Some documents refer to the DNS ID as the DNS "Query ID"
| or "TxID".
For more than 30 years, a large number of implementations of IETF
protocols have been subject to a variety of attacks, with effects protocols have been subject to a variety of attacks, with effects
ranging from Denial of Service (DoS) or data injection, to ranging from Denial of Service (DoS) or data injection to information
information leakages that could be exploited for pervasive monitoring leakages that could be exploited for pervasive monitoring [RFC7258].
[RFC7258]. The root cause of these issues has been, in many cases, The root cause of these issues has been, in many cases, the poor
poor selection of transient numeric identifiers, usually as a result selection of transient numeric identifiers in such protocols, usually
of insufficient or misleading specifications. as a result of insufficient or misleading specifications. While it
is generally trivial to identify an algorithm that can satisfy the
interoperability requirements of a given transient numeric
identifier, empirical evidence exists that doing so without
negatively affecting the security and/or privacy properties of the
aforementioned protocols is prone to error.
For example, implementations have been subject to security or privacy For example, implementations have been subject to security and/or
issues resulting from: privacy issues resulting from:
* Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. * predictable IPv4 or IPv6 Identification values (e.g., see
[Sanfilippo1998a], [RFC6274], and [RFC7739]) [Sanfilippo1998a], [RFC6274], and [RFC7739]),
* Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and * predictable IPv6 IIDs (e.g., see [RFC7217], [RFC7707], and
[RFC7217]) [RFC7721]),
* Predictable transport protocol ephemeral port numbers (see e.g. * predictable transport-protocol ephemeral port numbers (e.g., see
[RFC6056] and [Silbersack2005]) [RFC6056] and [Silbersack2005]),
* Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. * predictable TCP Initial Sequence Numbers (ISNs) (e.g., see
[Morris1985], [Bellovin1989], and [RFC6528]) [Morris1985], [Bellovin1989], and [RFC6528]),
* Predictable DNS Query IDs (see e.g. [Arce1997] and [Klein2007]) * predictable initial timestamps in TCP timestamps options (e.g.,
see [TCPT-uptime] and [RFC7323]), and
These examples indicate that when new protocols are standardized or * predictable DNS IDs (see, e.g., [Schuba1993] and [Klein2007]).
implemented, the security and privacy properties of the associated
transient numeric identifiers tend to be overlooked, and Recent history indicates that, when new protocols are standardized or
inappropriate algorithms to generate such identifiers (i.e. that new protocol implementations are produced, the security and privacy
negatively affect the security or privacy properties of the protocol) properties of the associated transient numeric identifiers tend to be
are either suggested in the specification or selected by overlooked, and inappropriate algorithms to generate such identifiers
implementers. are either suggested in the specifications or selected by
implementers. As a result, advice in this area is warranted.
This document contains a non-exhaustive timeline of the specification This document contains a non-exhaustive timeline of the specification
and vulnerability disclosures related to some sample transient and vulnerability disclosures related to some sample transient
numeric identifiers, including other work that has led to advances in numeric identifiers, including other work that has led to advances in
this area. This analysis indicates that: this area. This analysis indicates that:
* Vulnerabilities associated with the inappropriate generation of * vulnerabilities associated with the inappropriate generation of
transient numeric identifiers have affected protocol transient numeric identifiers have affected protocol
implementations for an extremely long period of time. implementations for an extremely long period of time,
* Such vulnerabilities, even when addressed for a given protocol * such vulnerabilities, even when addressed for a given protocol
version, were later reintroduced in new versions or new version, were later reintroduced in new versions or new
implementations of the same protocol. implementations of the same protocol, and
* Standardization efforts that discuss and provide advice in this * standardization efforts that discuss and provide advice in this
area can have a positive effect on IETF specifications and their area can have a positive effect on IETF specifications and their
corresponding implementations. corresponding implementations.
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. Other properties of the corresponding protocols is nontrivial. Other
related documents ([I-D.irtf-pearg-numeric-ids-generation] and related documents ([RFC9415] and [RFC9416]) provide guidance in this
[I-D.gont-numeric-ids-sec-considerations]) provide guidance in this
area, as motivated by the present document. area, as motivated by the present document.
This document represents the consensus of the Privacy Enhancement and This document represents the consensus of the Privacy Enhancements
Assessment Research Group (PEARG). and Assessments Research Group (PEARG).
2. Terminology 2. Terminology
Transient Numeric Identifier: Transient Numeric Identifier:
A data object in a protocol specification that can be used to A data object in a protocol specification that can be used to
definitely distinguish a protocol object (a datagram, network definitely distinguish a protocol object (a datagram, network
interface, transport protocol endpoint, session, etc) from all interface, transport-protocol endpoint, session, etc.) from all
other objects of the same type, in a given context. Transient other objects of the same type, in a given context. Transient
numeric identifiers are usually defined as a series of bits, and numeric identifiers are usually defined as a series of bits and
represented using integer values. These identifiers are typically represented using integer values. These identifiers are typically
dynamically selected, as opposed to statically-assigned numeric dynamically selected, as opposed to statically assigned numeric
identifiers (see e.g. [IANA-PROT]). We note that different identifiers (e.g., see [IANA-PROT]). We note that different
identifiers may have additional requirements or properties transient numeric identifiers may have additional requirements or
depending on their specific use in a protocol. We use the term properties depending on their specific use in a protocol. We use
"transient numeric identifier" (or simply "numeric identifier" or the term "transient numeric identifier" (or simply "numeric
"identifier" as short forms) as a generic term to refer to any identifier" or "identifier" as short forms) as a generic term to
data object in a protocol specification that satisfies the refer to any data object in a protocol specification that
identification property stated above. satisfies the identification property stated above.
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 [RFC7721]. interpreted as defined in [RFC7721].
3. Threat Model 3. Threat Model
Throughout this document, we do not consider on-path attacks. That Throughout this document, we do not consider on-path attacks. That
is, we assume the attacker does not have physical or logical access is, we assume the attacker does not have physical or logical access
to the system(s) being attacked, and that the attacker can only to the system(s) being attacked and that the attacker can only
observe traffic explicitly directed to the attacker. Similarly, an observe traffic explicitly directed to the attacker. Similarly, an
attacker cannot observe traffic transferred between a sender and the attacker cannot observe traffic transferred between the sender and
receiver(s) of a target protocol, but may be able to interact with 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 any of these entities, including by, e.g., sending any traffic to
to sample transient numeric identifiers employed by the target them to sample transient numeric identifiers employed by the target
systems when communicating with the attacker. hosts when communicating with the attacker.
For example, when analyzing vulnerabilities associated with TCP For example, when analyzing vulnerabilities associated with TCP
Initial Sequence Numbers (ISNs), we consider the attacker is unable Initial Sequence Numbers (ISNs), we consider the attacker is unable
to capture network traffic corresponding to a TCP connection between to capture network traffic corresponding to a TCP connection between
two other hosts. However, we consider the attacker is able to two other hosts. However, we consider the attacker is able to
communicate with any of these hosts (e.g., establish a TCP connection 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 with any of them) to, e.g., sample the TCP ISNs employed by these
systems when communicating with the attacker. hosts when communicating with the attacker.
Similarly, when considering host-tracking attacks based on IPv6 Similarly, when considering host-tracking attacks based on IPv6
interface identifiers, we consider an attacker may learn the IPv6 Interface Identifiers, we consider an attacker may learn the IPv6
address employed by a victim node if e.g. the address becomes exposed address employed by a victim host if, e.g., the address becomes
as a result of the victim node communicating with an attacker- exposed as a result of the victim host communicating with an
operated server. Subsequently, an attacker may perform host-tracking attacker-operated server. Subsequently, an attacker may perform
by probing a set of target addresses composed by a set of target host-tracking by probing a set of target addresses composed by a set
prefixes and the IPv6 interface identifier originally learned by the of target prefixes and the IPv6 Interface Identifier originally
attacker. Alternatively, an attacker may perform host tracking if learned by the attacker. Alternatively, an attacker may perform
e.g. the victim node communicates with an attacker-operated server as host-tracking if, e.g., the victim host communicates with an
it moves from one location to another, those exposing its configured attacker-operated server as it moves from one location to another,
addresses. We note that none of these scenarios requires the thereby exposing its configured addresses. We note that none of
attacker observe traffic not explicitly directed to the attacker. these scenarios require the attacker observe traffic not explicitly
directed to the attacker.
4. Issues with the Specification of Transient Numeric Identifiers 4. Issues with the Specification of Transient Numeric Identifiers
While assessing IETF protocol specifications regarding the use of While assessing IETF protocol specifications regarding the use of
transient numeric identifiers, we have found that most of the issues transient numeric identifiers, we have found that most of the issues
discussed in this document arise as a result of one of the following discussed in this document arise as a result of one of the following
conditions: conditions:
* Protocol specifications that under-specify the requirements for * protocol specifications that under specify their transient numeric
their transient numeric identifiers identifiers
* Protocol specifications that over-specify their transient numeric * protocol specifications that over specify their transient numeric
identifiers identifiers
* Protocol implementations that simply fail to comply with the * protocol implementations that simply fail to comply with the
specified requirements specified requirements
A number of IETF protocol specifications have simply overlooked the A number of IETF protocol specifications under specified their
security and privacy implications of transient numeric identifiers. transient numeric identifiers, thus leading to implementations that
Examples of them are the specification of TCP ephemeral ports in were vulnerable to numerous off-path attacks. Examples of them are
[RFC0793], the specification of TCP sequence numbers in [RFC0793], or the specification of TCP local ports in [RFC0793] or the
the specification of the DNS TxID in [RFC1035]. specification of the DNS ID in [RFC1035].
| NOTE: The TCP local port in an active OPEN request is commonly
| known as the "ephemeral port" of the corresponding TCP
| connection [RFC6056].
On the other hand, there are a number of IETF protocol specifications On the other hand, there are a number of IETF protocol specifications
that over-specify some of their associated transient numeric that over specify some of their associated transient numeric
identifiers. For example, [RFC4291] essentially overloads the identifiers. For example, [RFC4291] essentially overloads the
semantics of IPv6 Interface Identifiers (IIDs) by embedding link- semantics of IPv6 Interface Identifiers (IIDs) by embedding link-
layer addresses in the IPv6 IIDs, when the interoperability layer addresses in the IPv6 IIDs when the interoperability
requirement of uniqueness could be achieved in other ways that do not requirement of uniqueness could be achieved in other ways that do not
result in negative security and privacy implications [RFC7721]. result in negative security and privacy implications [RFC7721].
Similarly, [RFC2460] suggested the use of a global counter for the Similarly, [RFC2460] suggests the use of a global counter for the
generation of Fragment Identification values, when the generation of Identification values when the interoperability
interoperability properties of uniqueness per {Src IP, Dst IP} could requirement of uniqueness per {IPv6 Source Address, IPv6 Destination
be achieved with other algorithms that do not result in negative Address} could be achieved with other algorithms that do not result
security and privacy implications [RFC7739]. in negative security and privacy implications [RFC7739].
Finally, there are implementations that simply fail to comply with Finally, there are protocol implementations that simply fail to
the corresponding IETF protocol specifications or recommendations. comply with existing protocol specifications. For example, some
For example, some popular operating systems (notably Microsoft popular operating systems still fail to implement transport-protocol
Windows) still fail to implement transport protocol ephemeral port ephemeral port randomization, as recommended in [RFC6056], or TCP
randomization, as recommended in [RFC6056]. Initial Sequence Number randomization, as recommended in [RFC9293].
The following subsections document the timelines for a number of The following subsections document the timelines for a number of
sample transient numeric identifiers, that illustrate how the problem sample transient numeric identifiers that illustrate how the problem
discussed in this document has affected protocols from different discussed in this document has affected protocols from different
layers over time. These sample transient numeric identifiers have layers over time. These sample transient numeric identifiers have
different interoperability requirements and failure severities (see different interoperability requirements and failure severities (see
Section 6 of [I-D.irtf-pearg-numeric-ids-generation]), and thus are Section 6 of [RFC9415]), and thus are considered to be representative
considered to be representative of the problem being analyzed in this of the problem being analyzed in this document.
document.
4.1. IPv4/IPv6 Identification 4.1. IPv4/IPv6 Identification
This section presents the timeline of the Identification field This section presents the timeline of the Identification field
employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). employed by IPv4 (in the base header) and IPv6 (in Fragment Headers).
The reason for presenting both cases in the same section is to make The reason for presenting both cases in the same section is to make
it evident that while the Identification value serves the same it evident that, while the Identification value serves the same
purpose in both IPv4 and IPv6, the work and research done for the purpose in both protocols, the work and research done for the IPv4
IPv4 case did not affect IPv6 specifications or implementations. case did not influence IPv6 specifications or implementations.
The IPv4 Identification is specified in [RFC0791], which specifies The IPv4 Identification is specified in [RFC0791], which specifies
the interoperability requirements for the Identification field: the the interoperability requirements for the Identification field, i.e.,
sender must choose the Identification field to be unique for a given the sender must choose the Identification field to be unique for a
source address, destination address, and protocol, for the time the given {Source Address, Destination Address, Protocol} for the time
datagram (or any fragment of it) could be alive in the internet. It the datagram (or any fragment of it) could be alive in the Internet.
suggests that a node may keep "a table of Identifiers, one entry for It suggests that a sending protocol module may keep "a table of
each destination it has communicated with in the last maximum packet Identifiers, one entry for each destination it has communicated with
lifetime for the internet", and suggests that "since the Identifier in the last maximum packet lifetime for the [I]nternet", and it also
field allows 65,536 different values, hosts may be able to simply use suggests that "since the Identifier field allows 65,536 different
unique identifiers independent of destination". The above has been values, hosts may be able to simply use unique identifiers
interpreted numerous times as a suggestion to employ per-destination independent of destination". The above has been interpreted numerous
or global counters for the generation of Identification values. times as a suggestion to employ per-destination or global counters
While [RFC0791] does not suggest any flawed algorithm for the for the generation of Identification values. While [RFC0791] does
generation of Identification values, the specification omits a not suggest any flawed algorithm for the generation of Identification
discussion of the security and privacy implications of predictable values, the specification omits a discussion of the security and
Identification values. This has resulted in many IPv4 privacy implications of predictable Identification values. This
implementations generating predictable fragment Identification values resulted in many IPv4 implementations generating predictable
by means of a global counter, at least at some point in time. Identification values by means of a global counter, at least at some
point in time.
The IPv6 Identification was originally specified in [RFC1883]. It The IPv6 Identification was originally specified in [RFC1883]. It
serves the same purpose as its IPv4 counterpart, with the only serves the same purpose as its IPv4 counterpart, but rather than
difference residing in the length of the corresponding field, and being part of the base header (as in the IPv4 case), it is part of
that while the IPv4 Identification field is part of the base IPv4 the Fragment Header (which may or may not be present in an IPv6
header, in the IPv6 case it is part of the Fragment header (which may packet). Section 4.5 of [RFC1883] states that the Identification
or may not be present in an IPv6 packet). [RFC1883] states, in must be different than that of any other fragmented packet sent
Section 4.5, that the Identification must be different than that of recently (within the maximum likely lifetime of a packet) with the
any other fragmented packet sent recently (within the maximum likely same Source Address and Destination Address. Subsequently, it notes
lifetime of a packet) with the same Source Address and Destination that this requirement can be met by means of a wrap-around 32-bit
Address. Subsequently, it notes that this requirement can be met by counter that is incremented each time a packet must be fragmented and
means of a wrap-around 32-bit counter that is incremented each time a that it is an implementation choice whether to use a global or a per-
packet must be fragmented, and that it is an implementation choice destination counter. Thus, the specification of the IPv6
whether to use a global or a per-destination counter. Thus, the Identification is similar to that of the IPv4 case, with the only
implementation of the IPv6 Identification is similar to that of the difference that, in the IPv6 case, the suggestions to use simple
IPv4 case, with the only difference that in the IPv6 case the counters is more explicit. [RFC2460] is the first revision of the
suggestions to use simple counters is more explicit. [RFC2460] was core IPv6 specification and maintains the same text for the
the first revision of the core IPv6 specification, and maintained the specification of the IPv6 Identification field. [RFC8200], the
same text for the specification of the IPv6 Identification field. second revision of the core IPv6 specification, removes the
[RFC8200], the second revision of the core IPv6 specification, suggestion from [RFC2460] to use a counter for the generation of IPv6
removes the suggestion from [RFC2460] to use a counter for the Identification values and points to [RFC7739] for sample algorithms
generation of IPv6 Identification values, and points to [RFC7739] for for their generation.
sample algorithms for their generation.
September 1981: September 1981:
[RFC0791] specifies the interoperability requirements for IPv4 [RFC0791] specifies the interoperability requirements for the IPv4
Identification value, but does not perform a vulnerability Identification but does not perform a vulnerability assessment of
assessment of this transient numeric identifier. this transient numeric identifier.
December 1995: December 1995:
[RFC1883], the first specification of the IPv6 protocol, is [RFC1883], the first specification of the IPv6 protocol, is
published. It suggests that a counter be used to generate the published. It suggests that a counter be used to generate the
IPv6 Identification value, and notes that it is an implementation IPv6 Identification values and notes that it is an implementation
choice whether to maintain a single counter for the node or choice whether to maintain a single counter for the node or
multiple counters, e.g., one for each of the node's possible multiple counters (e.g., one for each of the node's possible
source addresses, or one for each active (source address, Source Addresses, or one for each active {Source Address,
destination address) combination. Destination Address} set).
December 1998: December 1998:
[Sanfilippo1998a] finds that predictable IPv4 Identification [Sanfilippo1998a] finds that predictable IPv4 Identification
values (generated by most popular implementations) can be values (as generated by most popular implementations) can be
leveraged to count the number of packets sent by a target node. leveraged to count the number of packets sent by a target node.
[Sanfilippo1998b] explains how to leverage the same vulnerability [Sanfilippo1998b] explains how to leverage the same vulnerability
to implement a port-scanning technique known as "dumb/idle scan". to implement a port-scanning technique known as "idle scan". A
A tool that implements this attack is publicly released. tool that implements this attack is publicly released.
December 1998: December 1998:
[RFC2460], a revision of the IPv6 specification, is published, [RFC2460], a revision of the IPv6 specification, is published,
obsoleting [RFC1883]. It maintains the same specification of the obsoleting [RFC1883]. It maintains the same specification of the
IPv6 Identification field as its predecessor ([RFC1883]). IPv6 Identification field as its predecessor [RFC1883].
December 1998: December 1998:
OpenBSD implements randomization of the IPv4 Identification field OpenBSD implements randomization of the IPv4 Identification field
[OpenBSD-IPv4-ID]. [OpenBSD-IPv4-ID].
November 1999: November 1999:
[Sanfilippo1999] discusses how to leverage predictable IPv4 [Sanfilippo1999] discusses how to leverage predictable IPv4
Identification to uncover the rules of a number of firewalls. Identification values to uncover the rules of a number of
firewalls.
September 2002: September 2002:
[Fyodor2002] documents the implementation of the "idle/dumb scan" [Fyodor2002] documents the implementation of the "idle scan"
technique in the popular nmap tool. technique in the popular Network Mapper (nmap) tool.
November 2002: November 2002:
[Bellovin2002] explains how the IPv4 Identification field can be [Bellovin2002] explains how the IPv4 Identification field can be
exploited to count the number of systems behind a NAT. exploited to count the number of systems behind a NAT.
October 2003: October 2003:
OpenBSD implements randomization of the IPv6 Identification field OpenBSD implements randomization of the IPv6 Identification field
[OpenBSD-IPv6-ID]. [OpenBSD-IPv6-ID].
December 2003: December 2003:
[Zalewski2003] explains a technique to perform TCP data injection [Zalewski2003] explains a technique to perform TCP data injection
attacks based on predictable IPv4 identification values, which attacks based on predictable IPv4 Identification values, which
requires less effort than TCP injection attacks performed with requires less effort than TCP injection attacks performed with
bare TCP packets. bare TCP packets.
November 2005: January 2005:
[Silbersack2005] discusses shortcomings in a number of techniques [Silbersack2005] discusses shortcomings in a number of techniques
to mitigate predictable IPv4 Identification values. to mitigate predictable IPv4 Identification values.
October 2007: October 2007:
[Klein2007] describes a weakness in the pseudo random number [Klein2007] describes a weakness in the pseudorandom number
generator (PRNG) in use for the generation of the IP generator (PRNG) in use for the generation of IP Identification
Identification by a number of operating systems. values by a number of operating systems.
June 2011: June 2011:
[Gont2011] describes how to perform dumb/idle scan attacks in [Gont2011] describes how to perform idle scan attacks in IPv6.
IPv6.
November 2011: November 2011:
Linux mitigates predictable IPv6 Identification values Linux mitigates predictable IPv6 Identification values
[RedHat2011] [SUSE2011] [Ubuntu2011]. [RedHat2011] [SUSE2011] [Ubuntu2011].
December 2011: December 2011:
[draft-gont-6man-predictable-fragment-id-00] describes the [draft-gont-6man-predictable-fragment-id-00] describes the
security implications of predictable IPv6 Identification values, security implications of predictable IPv6 Identification values
and possible mitigations. This document has the Intended Status and possible mitigations. This document has the intended status
of "Standards Track", with the intention to formally update of "Standards Track", with the intention to formally update
[RFC2460], to introduce security and privacy requirements on the [RFC2460] to introduce security and privacy requirements on the
generation of IPv6 Identification values. generation of IPv6 Identification values.
May 2012: May 2012:
[Gont2012] notes that some major IPv6 implementations still employ [Gont2012] notes that some major IPv6 implementations still employ
predictable IPv6 Identification values. predictable IPv6 Identification values.
March 2013: March 2013:
The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but The 6man WG adopts [draft-gont-6man-predictable-fragment-id-03]
changes the track to "BCP" (while still formally updating but changes the track to "BCP" (while still formally updating
[RFC2460]), publishing the resulting document as [RFC2460]), posting the resulting document as
[draft-ietf-6man-predictable-fragment-id-00]. [draft-ietf-6man-predictable-fragment-id-00].
June 2013: June 2013:
A patch to incorporate support for IPv6-based idle/dumb scans in A patch to incorporate support for IPv6-based idle scans in nmap
nmap is submitted [Morbitzer2013]. is submitted [Morbitzer2013].
December 2014: December 2014:
The 6man WG changes the Intended Status of The 6man WG changes the intended status of
[draft-ietf-6man-predictable-fragment-id-01] to "Informational" [draft-ietf-6man-predictable-fragment-id-01] to "Informational"
and publishes it as [draft-ietf-6man-predictable-fragment-id-02]. and posts it as [draft-ietf-6man-predictable-fragment-id-02]. As
As a result, it no longer formally updates [RFC2460], and security a result, it no longer formally updates [RFC2460], and security
and privacy requirements on the generation of IPv6 Identification and privacy requirements on the generation of IPv6 Identification
values are eliminated. values are eliminated.
June 2015: June 2015:
[draft-ietf-6man-predictable-fragment-id-08] notes that some [draft-ietf-6man-predictable-fragment-id-08] notes that some
popular host and router implementations still employ predictable popular host and router implementations still employ predictable
IPv6 Identification values. IPv6 Identification values.
February 2016: February 2016:
[RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) [RFC7739] (based on [draft-ietf-6man-predictable-fragment-id-10])
analyzes the security and privacy implications of predictable IPv6 analyzes the security and privacy implications of predictable IPv6
Identification values, and provides guidance for selecting an Identification values and provides guidance for selecting an
algorithm to generate such values. However, being published with algorithm to generate such values. However, being published as an
the Intended Status of "Informational", it does not formally "Informational" RFC, it does not formally update [RFC2460] and
update [RFC2460], and does not introduce security and privacy
requirements on the generation of IPv6 Identification values.
June 2016:
[I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the
suggestion from RFC2460 to use a counter for the generation of
IPv6 Identification values, but does not perform a vulnerability
assessment of the generation of IPv6 Identification values, and
does not introduce security and privacy requirements on the does not introduce security and privacy requirements on the
generation of IPv6 Identification values. generation of IPv6 Identification values.
June 2016:
[draft-ietf-6man-rfc2460bis-05], a draft revision of [RFC2460],
removes the suggestion from [RFC2460] to use a counter for the
generation of IPv6 Identification values but does not perform a
vulnerability assessment of the generation of IPv6 Identification
values and does not introduce security and privacy requirements on
the generation of IPv6 Identification values.
July 2017: July 2017:
[I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], [draft-ietf-6man-rfc2460bis-13] is finally published as [RFC8200],
obsoleting [RFC2460], and pointing to [RFC7739] for sample obsoleting [RFC2460] and pointing to [RFC7739] for sample
algorithms for the generation of IPv6 Fragment Identification algorithms for the generation of IPv6 Identification values.
values. However, it does not introduce security and privacy However, it does not introduce security and privacy requirements
requirements on the generation of IPv6 Identification values. on the generation of IPv6 Identification values.
June 2019: October 2019:
[IPID-DEV] notes that the IPv6 ID generators of two popular [IPID-DEV] notes that the IPv6 Identification generators of two
operating systems are flawed. popular operating systems are flawed.
4.2. TCP Initial Sequence Numbers (ISNs) 4.2. TCP Initial Sequence Numbers (ISNs)
[RFC0793] suggests that the choice of the ISN of a connection is not [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 arbitrary but aims to reduce the chances of a stale segment from
being accepted by a new incarnation of a previous connection. being accepted by a new incarnation of a previous connection.
[RFC0793] suggests the use of a global 32-bit ISN generator that is [RFC0793] suggests the use of a global 32-bit ISN generator that is
incremented by 1 roughly every 4 microseconds. However, as a matter incremented by 1 roughly every 4 microseconds. However, as a matter
of fact, protection against stale segments from a previous of fact, protection against stale segments from a previous
incarnation of the connection is enforced by preventing the creation incarnation of the connection is enforced by preventing the creation
of a new incarnation of a previous connection before 2*MSL have of a new incarnation of a previous connection before 2*MSL has passed
passed since a segment corresponding to the old incarnation was last since a segment corresponding to the old incarnation was last seen
seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This is
is accomplished by the TIME-WAIT state and TCP's "quiet time" concept accomplished by the TIME-WAIT state and TCP's "quiet time" concept
(see Appendix B of [RFC1323]). Based on the assumption that ISNs are (see Appendix B of [RFC1323]). Based on the assumption that ISNs are
monotonically increasing across connections, many stacks (e.g., monotonically increasing across connections, many stacks (e.g.,
4.2BSD-derived) use the ISN of an incoming SYN segment to perform 4.2BSD-derived) use the ISN of an incoming SYN segment to perform
"heuristics" that enable the creation of a new incarnation of a "heuristics" that enable the creation of a new incarnation of a
connection while the previous incarnation is still in the TIME-WAIT connection while the previous incarnation is still in the TIME-WAIT
state (see p. 945 of [Wright1994]). This avoids an interoperability state (see p. 945 of [Wright1994]). This avoids an interoperability
problem that may arise when a node establishes connections to a problem that may arise when a node establishes connections to a
specific TCP end-point at a high rate [Silbersack2005]. specific TCP end-point at a high rate [Silbersack2005].
The interoperability requirements for TCP ISNs are probably not as The interoperability requirements for TCP ISNs are probably not as
clearly spelled out as one would expect. Furthermore, the suggestion clearly spelled out as one would expect. Furthermore, the suggestion
of employing a global counter in [RFC0793] negatively affects the of employing a global counter in [RFC0793] negatively affects the
security and privacy properties of the protocol. security and privacy properties of the protocol.
September 1981: September 1981:
[RFC0793], suggests the use of a global 32-bit ISN generator, [RFC0793] suggests the use of a global 32-bit ISN generator, whose
whose lower bit is incremented roughly every 4 microseconds. lower bit is incremented roughly every 4 microseconds. However,
However, such an ISN generator makes it trivial to predict the ISN such an ISN generator makes it trivial to predict the ISN that a
that a TCP instance will use for new connections, thus allowing a TCP implementation will use for new connections, thus allowing a
variety of attacks against TCP. variety of attacks against TCP.
February 1985: February 1985:
[Morris1985] was the first to describe how to exploit predictable [Morris1985] is the first to describe how to exploit predictable
TCP ISNs for forging TCP connections that could then be leveraged TCP ISNs for forging TCP connections that could then be leveraged
for trust relationship exploitation. for trust relationship exploitation.
April 1989: April 1989:
[Bellovin1989] discussed the security considerations for [Bellovin1989] discusses the security considerations for
predictable ISNs (along with a range of other protocol-based predictable ISNs (along with a range of other protocol-based
vulnerabilities). vulnerabilities).
February 1995: January 1995:
[Shimomura1995] reported a real-world exploitation of the attack [Shimomura1995] reports a real-world exploitation of the
described in [Morris1985] ten years before (in 1985). vulnerability described in [Morris1985] ten years before (in
1985).
May 1996: May 1996:
[RFC1948] was the first IETF effort, authored by Steven Bellovin, [RFC1948] is the first IETF effort, authored by Steven Bellovin,
to address predictable TCP ISNs. However, [RFC1948] does not to address predictable TCP ISNs. However, [RFC1948] does not
formally update [RFC0793]. The same concept specified in this formally update [RFC0793]. Note: The same concept specified in
document for TCP ISNs was later proposed for TCP ephemeral ports this document for TCP ISNs was later proposed for TCP ephemeral
[RFC6056], TCP Timestamps, and eventually even IPv6 Interface ports [RFC6056], TCP Timestamps, and eventually even IPv6
Identifiers [RFC7217]. Interface Identifiers [RFC7217].
July 1996: July 1996:
OpenBSD implements TCP ISN randomization based on random OpenBSD implements TCP ISN randomization based on random
increments (please see Appendix A.2 of increments (please see Appendix A.2 of [RFC9415])
[I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I]. [OpenBSD-TCP-ISN-I].
December 2000: December 2000:
OpenBSD implements TCP ISN randomization using simple OpenBSD implements TCP ISN randomization using simple
randomization (please see Section 7.1 of randomization (please see Section 7.1 of [RFC9415])
[I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R]. [OpenBSD-TCP-ISN-R].
March 2001: March 2001:
[Zalewski2001] provides a detailed analysis of statistical [Zalewski2001] provides a detailed analysis of statistical
weaknesses in some ISN generators, and includes a survey of the weaknesses in some TCP ISN generators and includes a survey of the
algorithms in use by popular TCP implementations. algorithms in use by popular TCP implementations. Vulnerability
advisories [USCERT2001] were released regarding statistical
May 2001: weaknesses in some TCP ISN generators, affecting popular TCP
Vulnerability advisories [CERT2001] [USCERT2001] were released implementations. Other vulnerability advisories on the same
regarding statistical weaknesses in some ISN generators, affecting vulnerability, such as [CERT2001], were published later on.
popular TCP implementations.
March 2002: March 2002:
[Zalewski2002] updates and complements [Zalewski2001]. It [Zalewski2002] updates and complements [Zalewski2001]. It
concludes that "while some vendors [...] reacted promptly and concludes that "while some vendors [...] reacted promptly and
tested their solutions properly, many still either ignored the tested their solutions properly, many still either ignored the
issue and never evaluated their implementations, or implemented a issue and never evaluated their implementations, or implemented a
flawed solution that apparently was not tested using a known flawed solution that apparently was not tested using a known
approach" [Zalewski2002]. approach" [Zalewski2002].
June 2007: June 2007:
OpenBSD implements TCP ISN randomization based on the algorithm OpenBSD implements TCP ISN randomization based on the algorithm
specified in [RFC1948] (currently obsoleted and replaced by specified in [RFC1948] (currently obsoleted and replaced by
[RFC6528]) for the TCP endpoint that performs the active open, [RFC6528]) for the TCP endpoint that performs the active open
while keeping the simple randomization scheme for the endpoint while keeping the simple randomization scheme for the endpoint
performing the passive open [OpenBSD-TCP-ISN-H]. This provides performing the passive open [OpenBSD-TCP-ISN-H]. This provides
monotonically-increasing ISNs for the client side (allowing the monotonically increasing ISNs for the "client side" (allowing the
BSD heuristics to work as expected), while avoiding any patterns BSD heuristics to work as expected) while avoiding any patterns in
in the ISN generation for the server side. the ISN generation for the "server side".
February 2012: February 2012:
[RFC6528], published 27 years after Morris' original work [RFC6528], published 27 years after Morris's original work
[Morris1985], formally updates [RFC0793] to mitigate predictable [Morris1985], formally updates [RFC0793] to mitigate predictable
TCP ISNs. TCP ISNs.
August 2014: August 2014:
[I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP The algorithm specified in [RFC6528] becomes the recommended
protocol specification, incorporates the algorithm specified in ("SHOULD") algorithm for TCP ISN generation in
[RFC6528] as the recommended ("SHOULD") algorithm for TCP ISN [draft-eddy-rfc793bis-04], an early revision of the core TCP
generation. specification [RFC9293].
August 2022:
[RFC9293], a revision of the core TCP specification, is published,
adopting the algorithm specified in [RFC6528] as the recommended
("SHOULD") algorithm for TCP ISN generation.
4.3. IPv6 Interface Identifiers (IIDs) 4.3. IPv6 Interface Identifiers (IIDs)
IPv6 Interface Identifiers can be generated as a result of different IPv6 Interface Identifiers can be generated as a result of different
mechanisms, including SLAAC [RFC4862], DHCPv6 [RFC8415], and manual mechanisms, including Stateless Address Autoconfiguration (SLAAC)
configuration. This section focuses on Interface Identifiers [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section
resulting from SLAAC. focuses on Interface Identifiers resulting from SLAAC.
The Interface Identifier of stable (traditional) IPv6 addresses The Interface Identifier of stable IPv6 addresses resulting from
resulting from SLAAC have traditionally resulted in the underlying SLAAC originally resulted in the underlying link-layer address being
link-layer address being embedded in the IID.At the time, employing embedded in the IID. At the time, employing the underlying link-
the underlying link-layer address for the IID was seen as a layer address for the IID was seen as a convenient way to obtain a
convenient way to obtain a unique address. However, recent awareness unique address. However, recent awareness about the security and
about the security and privacy properties of this approach [RFC7707] privacy properties of this approach [RFC7707] [RFC7721] has led to
[RFC7721] has led to the replacement of this flawed scheme with an the replacement of this flawed scheme with an alternative one
alternative one [RFC7217] [RFC8064] that does not negatively affect [RFC7217] [RFC8064] that does not negatively affect the security and
the security and privacy properties of the protocol. privacy properties of the protocol.
January 1997: January 1997:
[RFC2073] specifies the syntax of IPv6 global addresses (referred [RFC2073] specifies the syntax of IPv6 global addresses (referred
to as "An IPv6 Provider-Based Unicast Address Format" at the to as "An IPv6 Provider-Based Unicast Address Format" at the
time), consistent with the IPv6 addressing architecture specified time), which is consistent with the IPv6 addressing architecture
in [RFC1884]. Hosts are recommended to "generate addresses using specified in [RFC1884]. Hosts are recommended to "generate
link-specific addresses as Interface ID such as 48 bit IEEE-802 addresses using link-specific addresses as Interface ID such as 48
MAC addresses". bit IEEE-802 MAC addresses".
July 1998: July 1998:
[RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address
Format" (obsoleting [RFC2373]) changing the size of the IID to 64 Format" (obsoleting [RFC2073]), changing the size of the IID to 64
bits, and specifies that IIDs must be constructed in IEEE EUI-64 bits, and specifies that IIDs must be constructed in IEEE 64-bit
format. How such identifiers are constructed becomes specified in Extended Unique Identifier (EUI-64) format. How such identifiers
the corresponding "IPv6 over <link>" specifications, such as "IPv6 are constructed is specified in the corresponding "IPv6 over
over Ethernet". <link>" specifications, such as "IPv6 over Ethernet".
January 2001: January 2001:
[RFC3041] recognizes the problem of network activity correlation, [RFC3041] recognizes the problem of IPv6 network activity
and specifies temporary addresses. Temporary addresses are to be correlation and specifies IPv6 temporary addresses. Temporary
used along with stable addresses. addresses are to be used along with stable addresses.
August 2003: August 2003:
[RFC3587] obsoletes [RFC2374], making the TLA/NLA structure [RFC3587] obsoletes [RFC2374], making the Top-Level Aggregator
historic. The syntax and recommendations for the traditional (TLA) / Next-Level Aggregator (NLA) structure historic, though the
stable IIDs remain unchanged, though. syntax and recommendations for the stable IIDs remain unchanged.
February 2006: February 2006:
[RFC4291] is published as the latest "IP Version 6 Addressing [RFC4291] is published as the latest "IP Version 6 Addressing
Architecture", requiring the IIDs of the traditional (stable) IPv6 Architecture", requiring the IIDs of "all unicast addresses,
addresses resulting from SLAAC to employ the Modified EUI-64 except those that start with the binary value 000" to employ the
format. The details of constructing such interface identifiers Modified EUI-64 format. The details of constructing such
are defined in the corresponding "IPv6 over <link>" interface identifiers are defined in the corresponding "IPv6 over
specifications. <link>" specifications.
March 2008: March 2008:
[RFC5157] provides hints regarding how patterns in IPv6 addresses [RFC5157] provides hints regarding how patterns in IPv6 addresses
could be leveraged for the purpose of address scanning. could be leveraged for the purpose of address scanning.
December 2011: December 2011:
[draft-gont-6man-stable-privacy-addresses-00] notes that the [draft-gont-6man-stable-privacy-addresses-00] notes that the
traditional scheme for generating stable addresses allows for original scheme for generating stable addresses allows for IPv6
address scanning, and also does not prevent active node tracking. address scanning and for active host tracking (even when IPv6
It also specifies an alternative algorithm meant to replace IIDs temporary addresses are employed). It also specifies an
based on Modified EUI-64 format identifiers. alternative algorithm meant to replace IIDs based on Modified
EUI-64 format identifiers.
November 2012: November 2012:
The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a The 6man WG adopts [draft-gont-6man-stable-privacy-addresses-01]
working group item (as as a working group item (as
[draft-ietf-6man-stable-privacy-addresses-00]). However, the [draft-ietf-6man-stable-privacy-addresses-00]). However, the
document no longer formally updates [RFC4291], and therefore the document no longer formally updates [RFC4291]; therefore, the
specified algorithm no longer formally replaces the Modified specified algorithm no longer formally replaces the Modified
EUI-64 format identifiers. EUI-64 format identifiers.
February 2013: February 2013:
An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages
IPv6 address patterns is released [Gont2013]. IPv6 address patterns is released [Gont2013].
July 2013: July 2013:
[I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on [draft-cooper-6man-ipv6-address-generation-privacy-00] elaborates
the security and privacy properties of all known algorithms for on the security and privacy properties of all known algorithms for
generating IPv6 IIDs. generating IPv6 IIDs.
January 2014: January 2014:
The 6man WG publishes [draft-ietf-6man-default-iids-00] The 6man WG posts [draft-ietf-6man-default-iids-00]
("Recommendation on Stable IPv6 Interface Identifiers"), ("Recommendation on Stable IPv6 Interface Identifiers"),
recommending [I-D.ietf-6man-stable-privacy-addresses] for the recommending [draft-ietf-6man-stable-privacy-addresses-17] for the
generation of stable addresses. generation of stable addresses.
April 2014: April 2014:
[RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) is [RFC7217] (formerly [draft-ietf-6man-stable-privacy-addresses-17])
published, specifying "A Method for Generating Semantically Opaque is published, specifying "A Method for Generating Semantically
Interface Identifiers with IPv6 Stateless Address Opaque Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)" as an alternative to (but *not* Autoconfiguration (SLAAC)" as an alternative to (but *not*
replacement of) Modified EUI-64 format IIDs. replacement of) Modified EUI-64 format IIDs.
March 2016: March 2016:
[RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], and later [RFC7707] (formerly [draft-gont-opsec-ipv6-host-scanning-02] and
[I-D.ietf-opsec-ipv6-host-scanning]), about "Network later [draft-ietf-opsec-ipv6-host-scanning-08]), about "Network
Reconnaissance in IPv6 Networks", is published. Reconnaissance in IPv6 Networks", is published.
March 2016: March 2016:
[RFC7721] (formerly [RFC7721] (formerly
[I-D.cooper-6man-ipv6-address-generation-privacy] and later [draft-cooper-6man-ipv6-address-generation-privacy-00] and later
[I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security [draft-ietf-6man-ipv6-address-generation-privacy-08]), about
and Privacy Considerations for IPv6 Address Generation "Security and Privacy Considerations for IPv6 Address Generation
Mechanisms", is published. Mechanisms", is published.
May 2016: May 2016:
[draft-gont-6man-non-stable-iids-00] is published, with the goal [draft-gont-6man-non-stable-iids-00] is posted, with the goal of
of specifying requirements for non-stable addresses, and updating specifying requirements for non-stable addresses and updating
[RFC4941] such that use of only temporary addresses is allowed. [RFC4941] such that use of only temporary addresses is allowed.
May 2016: May 2016:
[draft-gont-6man-address-usage-recommendations-00] is published, [draft-gont-6man-address-usage-recommendations-00] is posted,
providing an analysis of how different aspects on an address (from providing an analysis of how different aspects on an address (from
stability to usage mode) affect their corresponding security and stability to usage mode) affect their corresponding security and
privacy properties, and meaning to eventually provide advice in privacy properties and meaning to eventually provide advice in
this area. this area.
February 2017: February 2017:
The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6 [draft-ietf-6man-default-iids-16], produced by the 6man WG, is
Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), published as [RFC8064] ("Recommendation on Stable IPv6 Interface
with requirements for stable addresses and a recommendation to Identifiers"), with requirements for stable addresses and a
employ [RFC7217] for the generation of stable addresses. It recommendation to employ [RFC7217] for the generation of stable
formally updates a large number of RFCs. addresses. It formally updates a large number of RFCs.
March 2018: March 2018:
[draft-fgont-6man-rfc4941bis-00] is published (as suggested by the [draft-fgont-6man-rfc4941bis-00] is posted (as suggested by the
6man WG), to address flaws in [RFC4941] by revising it (as an 6man WG) to address flaws in [RFC4941] by revising it (as an
alternative to the [draft-gont-6man-non-stable-iids-00] effort, alternative to the [draft-gont-6man-non-stable-iids-00] effort,
published in March 2016). posted in March 2016).
July 2018: July 2018:
[draft-fgont-6man-rfc4941bis-00] is adopted (as [draft-fgont-6man-rfc4941bis-00] is adopted (as
[draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG. [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG.
December 2020: December 2020:
[I-D.ietf-6man-rfc4941bis] is approved by the IESG for publication [draft-ietf-6man-rfc4941bis-12] is approved by the IESG for
as an RFC. publication as an RFC.
February 2021: February 2021:
[I-D.ietf-6man-rfc4941bis] is finally published as [RFC8981]. [draft-ietf-6man-rfc4941bis-12] is finally published as [RFC8981].
4.4. NTP Reference IDs (REFIDs) 4.4. NTP Reference IDs (REFIDs)
The NTP [RFC5905] Reference ID is a 32-bit code identifying the The NTP [RFC5905] Reference ID is a 32-bit code identifying the
particular server or reference clock. Above stratum 1 (secondary particular server or reference clock. Above stratum 1 (secondary
servers and clients), this value can be employed to avoid degree-one servers and clients), this value can be employed to avoid degree-one
timing loops; that is, scenarios where two NTP peers are (mutually) timing loops, that is, scenarios where two NTP peers are (mutually)
the time source of each other. If using the IPv4 address family, the the time source of each other. If using the IPv4 address family, the
identifier is the four-octet IPv4 address. If using the IPv6 address identifier is the four-octet IPv4 address. If using the IPv6 address
family, it is the first four octets of the MD5 hash of the IPv6 family, it is the first four octets of the MD5 hash of the IPv6
address. address.
June 2010: June 2010:
[RFC5905], "Network Time Protocol Version 4: Protocol and [RFC5905] ("Network Time Protocol Version 4: Protocol and
Algorithms Specification" is published. It specifies that for NTP Algorithms Specification") is published. It specifies that, for
peers with stratum higher than 1 the REFID embeds the IPv4 Address NTP peers with stratum higher than 1, the REFID embeds the IPv4
of the time source or an MD5 hash of the IPv6 address of the time address of the time source or the first four octets of the MD5
source. hash of the IPv6 address of the time source.
July 2016: July 2016:
[draft-stenn-ntp-not-you-refid-00] is published, describing the [draft-stenn-ntp-not-you-refid-00] is posted, describing the
information leakage produced via the NTP REFID. It proposes that information leakage produced via the NTP REFID. It proposes that
NTP returns a special REFID when a packet employs an IP Source NTP returns a special REFID when a packet employs an IP Source
Address that is not believed to be a current NTP peer, but Address that is not believed to be a current NTP peer but
otherwise generates and returns the traditional REFID. It is otherwise generates and returns the common REFID. It is
subsequently adopted by the NTP WG as subsequently adopted by the NTP WG as
[I-D.ietf-ntp-refid-updates]. [draft-ietf-ntp-refid-updates-00].
April 2019: April 2019:
[Gont-NTP] notes that the proposed fix specified in [Gont-NTP] notes that the proposed fix specified in
[draft-ietf-ntp-refid-updates-00] is, at the very least, sub- [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-
optimal. As a result of lack of WG support, the effort is optimal. As a result of a lack of WG support, the
eventually abandoned. [draft-ietf-ntp-refid-updates-00] effort is eventually abandoned.
4.5. Transport Protocol Ephemeral Port Numbers 4.5. Transport-Protocol Ephemeral Port Numbers
Most (if not all) transport protocols employ "port numbers" to Most (if not all) transport protocols employ "port numbers" to
demultiplex packets to the corresponding transport protocol demultiplex packets to the corresponding transport-protocol
instances. instances. "Ephemeral ports" refer to the local ports employed in
active OPEN requests, that is, typically the local port numbers
employed on the side initiating the communication.
August 1980: August 1980:
[RFC0768] notes that the UDP source port is optional and [RFC0768] notes that the UDP source port is optional and
identifies the port of the sending process. It does not specify identifies the port of the sending process. It does not specify
interoperability requirements for source port selection, nor does interoperability requirements for source port selection, nor does
it suggest possible ways to select port numbers. Most popular it suggest possible ways to select port numbers. Most popular
implementations end up selecting source ports from a system-wide implementations end up selecting source ports from a system-wide
global counter. global counter.
September 1981: September 1981:
[RFC0793] (the TCP specification) essentially describes the use of [RFC0793] (the TCP specification) essentially describes the use of
port numbers, and specifies that port numbers should result in a port numbers and specifies that port numbers should result in a
unique socket pair (local address, local port, remote address, unique socket pair {local address, local port, remote address,
remote port). How ephemeral ports (i.e. port numbers for "active remote port}. How ephemeral ports are selected and the port range
opens") are selected, and the port range from which they are from which they are selected are left unspecified.
selected, are left unspecified.
July 1996: July 1996:
OpenBSD implements ephemeral port randomization [OpenBSD-PR]. OpenBSD implements ephemeral port randomization [OpenBSD-PR].
July 2008: July 2008:
The CERT Coordination Centre published details of what became The CERT Coordination Center publishes details of what became
known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the
DNS. The attack exploited the lack of source port randomization DNS. The attack exploits the lack of ephemeral port randomization
in many major DNS implementations to perform cache poisoning in an and DNS ID randomization in many major DNS implementations to
effective and practical manner. perform cache poisoning in an effective and practical manner.
January 2009: January 2009:
[RFC5452] mandates the use of port randomization for DNS [RFC5452] mandates the use of port randomization for DNS resolvers
resolvers, and mandates that implementations must randomize ports and mandates that implementations must randomize ports from the
from the range (53 or 1024, and above) or the largest possible range of available ports (53 or 1024 and above) that is as large
port range. It does not recommend possible algorithms for port as possible and practicable. It does not recommend possible
randomization, although the document specifically targets DNS algorithms for port randomization, although the document
resolvers, for which a simple port randomization suffices (e.g. specifically targets DNS resolvers, for which a simple port
Algorithm 1 of [RFC6056]). This document led to the randomization suffices (e.g., Algorithm 1 of [RFC6056]). This
implementation of port randomization in the DNS resolver document led to the implementation of port randomization in the
themselves, rather than in the underlying transport-protocols. DNS resolvers themselves, rather than in the underlying transport
protocols.
January 2011: January 2011:
[RFC6056] notes that many TCP and UDP implementations result in [RFC6056] notes that many TCP and UDP implementations result in
predictable port numbers, and also notes that many implementations predictable ephemeral port numbers and also notes that many
select port numbers from a small portion of the whole port number implementations select port numbers from a small portion of the
space. It recommends the implementation and use of ephemeral port whole port number space. It recommends the implementation and use
randomization, proposes a number of possible algorithms for port of ephemeral port randomization, proposes a number of possible
randomization, and also recommends to randomize port numbers over algorithms for port randomization, and also recommends to
the range 1024-65535. randomize port numbers over the range 1024-65535.
March 2016: March 2016:
[NIST-NTP] reports a non-normal distribution of the ephemeral port [NIST-NTP] reports a non-normal distribution of the ephemeral port
numbers employed by the NTP clients of an Internet Time Service. numbers employed by the NTP clients of an Internet Time Service.
April 2019: April 2019:
[I-D.gont-ntp-port-randomization] notes that some NTP [draft-gont-ntp-port-randomization-00] notes that some NTP
implementations employ the NTP service port (123) as the local implementations employ the NTP service port (123) as the local
port for non-symmetric modes, and aims to update the NTP port for nonsymmetric modes and aims to update the NTP
specification to recommend port randomization in such cases, in specification to recommend port randomization in such cases, which
line with [RFC6056]. The proposal experiences some push-back in is in line with [RFC6056]. The proposal experiences some pushback
the relevant working group (NTP WG) [NTP-PORTR], but is finally in the relevant working group (NTP WG) [NTP-PORTR] but is finally
adopted as a working group item as adopted as a working group item as
[I-D.ietf-ntp-port-randomization]. [draft-ietf-ntp-port-randomization-00].
August 2021: August 2021:
[I-D.ietf-ntp-port-randomization] is finally published as [draft-ietf-ntp-port-randomization-08] is finally published as
[RFC9109]. [RFC9109].
4.6. DNS Query ID 4.6. DNS ID
The DNS Query ID [RFC1035] can be employed to match DNS replies to The DNS ID [RFC1035] can be employed to match DNS replies to
outstanding DNS queries. outstanding DNS queries.
| NOTE: Some documents refer to the DNS ID as the DNS "Query ID"
| or "TxID".
November 1987: November 1987:
[RFC1035] specifies that the ID is a 16 bit identifier assigned by [RFC1035] specifies that the DNS ID is a 16-bit identifier
the program that generates any kind of query, and that this assigned by the program that generates any kind of query and that
identifier is copied in the corresponding reply and can be used by this identifier is copied in the corresponding reply and can be
the requester to match up replies to outstanding queries. It does used by the requester to match up replies to outstanding queries.
not specify the interoperability requirements for these numeric It does not specify the interoperability requirements for this
identifiers, nor does it suggest an algorithm for generating them. numeric identifier, nor does it suggest an algorithm for
generating it.
1993: August 1993:
[Schuba1993] describes DNS cache poisoning attacks that require [Schuba1993] describes DNS cache poisoning attacks that require
the attacker to guess the Query ID. the attacker to guess the DNS ID.
June 1995: June 1995:
[Vixie1995] suggests that both the UDP source port and the ID of [Vixie1995] suggests that both the UDP source port and the DNS ID
query packets should be randomized, although that might not of query packets should be randomized, although that might not
provide enough entropy to prevent an attacker from guessing these provide enough entropy to prevent an attacker from guessing these
values. values.
April 1997: April 1997:
[Arce1997] finds that implementations employ predictable UDP [Arce1997] finds that implementations employ predictable UDP
source ports and predictable Query IDs, and argues that both source ports and predictable DNS IDs and argues that both should
should be randomized. be randomized.
November 2002: November 2002:
[Sacramento2002] finds that by spoofing multiple requests for the [Sacramento2002] finds that, by spoofing multiple requests for the
same domain name from different IP addresses, an attacker may same domain name from different IP addresses, an attacker may
guess the Query ID employed for a victim with a high probability guess the DNS ID employed for a victim with a high probability of
of success, thus performing DNS cache poisoning attacks. success, thus allowing for DNS cache poisoning attacks.
March 2007:
[Klein2007c] finds that the Microsoft Windows DNS server generates
predictable DNS ID values.
July 2007: July 2007:
[Klein2007b] finds that a popular DNS server software (BIND 9) [Klein2007b] finds that a popular DNS server software (BIND 9)
that randomizes the Query ID is still subject to DNS cache that randomizes the DNS ID is still subject to DNS cache poisoning
poisoning attacks by forging a large number of queries and attacks by forging a large number of queries and leveraging the
leveraging the birthday paradox. birthday paradox.
March 2007:
[Klein2007c] finds that Microsoft Windows DNS Server generates
predictable Query ID values.
October 2007: October 2007:
[Klein2007] finds that OpenBSD's DNS software (based on ISC's BIND [Klein2007] finds that OpenBSD's DNS software (based on the BIND
DNS Server) generates predictable Query ID values. DNS server of the Internet Systems Consortium (ISC)) generates
predictable DNS ID values.
January 2009: January 2009:
[RFC5452] is published, requiring resolvers to randomize the Query [RFC5452] is published, requiring resolvers to randomize the DNS
ID of DNS queries, and to verify that the Query ID of a DNS reply ID of queries and to verify that the DNS ID of a reply matches
matches that of the DNS query as part of the DNS reply validation that of the DNS query as part of the DNS reply validation process.
process.
May 2010: May 2010:
[Economou2010] finds that Windows SMTP Service implements its own [Economou2010] finds that the Windows SMTP Service implements its
DNS resolver that results in predictable Query ID values. own DNS resolver that results in predictable DNS ID values.
Additionally, it fails to validate that the Query ID of DNS reply Additionally, it fails to validate that the DNS ID of a reply
matches the one from the DNS query that supposedly elicited the matches that of the DNS query that supposedly elicited it.
reply.
5. Conclusions 5. Conclusions
For more than 30 years, a large number of implementations of the IETF For more than 30 years, a large number of implementations of IETF
protocols have been subject to a variety of attacks, with effects protocols have been subject to a variety of attacks, with effects
ranging from Denial of Service (DoS) or data injection, to ranging from Denial of Service (DoS) or data injection to information
information leakages that could be exploited for pervasive monitoring leakages that could be exploited for pervasive monitoring [RFC7258].
[RFC7258]. The root cause of these issues has been, in many cases, The root cause of these issues has been, in many cases, the poor
poor selection of transient numeric identifiers, usually as a result selection of transient numeric identifiers in such protocols, usually
of insufficient or misleading specifications. as a result of insufficient or misleading specifications.
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 properties of the aforementioned protocols is nontrivial. It is thus
thus evident that advice in this area is warranted. evident that advice in this area is warranted.
[I-D.gont-numeric-ids-sec-considerations] aims at requiring future [RFC9416] aims at requiring future IETF protocol specifications to
IETF protocol specifications to contain analysis of the security and contain analysis of the security and privacy properties of any
privacy properties of any transient numeric identifiers specified by transient numeric identifiers specified by the protocol and to
the protocol, and to recommend an algorithm for the generation of recommend an algorithm for the generation of such transient numeric
such transient numeric identifiers. identifiers. [RFC9415] specifies a number of sample algorithms for
[I-D.irtf-pearg-numeric-ids-generation] specifies a number of sample generating transient numeric identifiers with specific
algorithms for generating transient numeric identifiers with specific interoperability requirements and failure severities.
interorability requirements and failure severities.
6. IANA Considerations 6. IANA Considerations
There are no IANA registries within this document. This document has no IANA actions.
7. Security Considerations 7. Security Considerations
This document analyzes the timeline of the specification and This document analyzes the timeline of the specification and
implementation of the transient numeric identifiers of some sample implementation of the transient numeric identifiers of some sample
IETF protocols, and how the security and privacy properties of such IETF protocols and how the security and privacy properties of such
protocols have been affected as a result of it. It provides concrete protocols have been affected as a result of it. It provides concrete
evidence that advice in this area is warranted. evidence that advice in this area is warranted.
[I-D.gont-numeric-ids-sec-considerations] formally requires IETF [RFC9415] analyzes and categorizes transient numeric identifiers
protocol specifications to specify the interoperability requirements based on their interoperability requirements and their associated
for their transient numeric identifiers, to do a warranted failure severities and recommends possible algorithms that can be
vulnerability assessment of such transient numeric identifiers, and employed to comply with those requirements without negatively
to recommend possible algorithms for their generation, such that the affecting the security and privacy properties of the corresponding
interoperability requirements are complied with, while any negative protocols.
security and privacy properties of these transient numeric
identifiers are mitigated.
[I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes
transient numeric identifiers based on their interoperability
requirements and their associated failure severities, and recommends
possible algorithms that can comply with those requirements without
negatively affecting the security and privacy properties of the
corresponding protocols.
8. Acknowledgements
The authors would like to thank (in alphabetical order) Bernard
Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson,
Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris
Shrishak, Joe Touch, Brian Trammell, and Christopher Wood, for
providing valuable comments on earlier versions of this document.
The authors would like to thank (in alphabetical order) Steven
Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
providing valuable comments on [I-D.gont-predictable-numeric-ids], on
which this document is based.
Section 4.2 of this document borrows text from [RFC6528], authored by
Fernando Gont and Steven Bellovin.
The authors would like to thank Sara Dickinson and Christopher Wood,
for their guidance during the publication process of this document.
The authors would like to thank Diego Armando Maradona for his magic [RFC9416] formally requires IETF protocol specifications to specify
and inspiration. the interoperability requirements for their transient numeric
identifiers, to do a warranted vulnerability assessment of such
transient numeric identifiers, and to recommend possible algorithms
for their generation, such that the interoperability requirements are
complied with, while any negative security or privacy properties of
these transient numeric identifiers are mitigated.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
DOI 10.17487/RFC0793, September 1981, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
2012, <https://www.rfc-editor.org/info/rfc6528>. 1992, <https://www.rfc-editor.org/info/rfc1323>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <https://www.rfc-editor.org/info/rfc1883>. December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1995, <https://www.rfc-editor.org/info/rfc1884>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
DOI 10.17487/RFC3041, January 2001,
<https://www.rfc-editor.org/info/rfc3041>.
[RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
Postel, "An IPv6 Provider-Based Unicast Address Format", Postel, "An IPv6 Provider-Based Unicast Address Format",
RFC 2073, DOI 10.17487/RFC2073, January 1997, RFC 2073, DOI 10.17487/RFC2073, January 1997,
<https://www.rfc-editor.org/info/rfc2073>. <https://www.rfc-editor.org/info/rfc2073>.
[RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374, Aggregatable Global Unicast Address Format", RFC 2374,
DOI 10.17487/RFC2374, July 1998, DOI 10.17487/RFC2374, July 1998,
<https://www.rfc-editor.org/info/rfc2374>. <https://www.rfc-editor.org/info/rfc2374>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
DOI 10.17487/RFC3041, January 2001,
<https://www.rfc-editor.org/info/rfc3041>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>. August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
December 1995, <https://www.rfc-editor.org/info/rfc1884>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
<https://www.rfc-editor.org/info/rfc2373>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Extensions for Stateless Address Autoconfiguration in
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc4941>.
<https://www.rfc-editor.org/info/rfc8415>.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May Resilient against Forged Answers", RFC 5452,
1992, <https://www.rfc-editor.org/info/rfc1323>. DOI 10.17487/RFC5452, January 2009,
<https://www.rfc-editor.org/info/rfc5452>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc6056>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Resilient against Forged Answers", RFC 5452, Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
DOI 10.17487/RFC5452, January 2009, 2012, <https://www.rfc-editor.org/info/rfc6528>.
<https://www.rfc-editor.org/info/rfc5452>.
9.2. Informative References
[OpenBSD-PR] [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
OpenBSD, "Implementation of port randomization", 29 July Interface Identifiers with IPv6 Stateless Address
1996, <https://cvsweb.openbsd.org/src/sys/netinet/ Autoconfiguration (SLAAC)", RFC 7217,
in_pcb.c?rev=1.6>. DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[VU-800113] [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
CERT/CC, "Multiple DNS implementations vulnerable to cache Scheffenegger, Ed., "TCP Extensions for High Performance",
poisoning (Vulnerability Note VU#800113)", 8 July 2008, RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.kb.cert.org/vuls/id/800113>. <https://www.rfc-editor.org/info/rfc7323>.
[IANA-PROT] [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
IANA, "Protocol Registries", (IPv6) Specification", STD 86, RFC 8200,
<https://www.iana.org/protocols>. DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
RFC 5157, DOI 10.17487/RFC5157, March 2008, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
<https://www.rfc-editor.org/info/rfc5157>. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
"Temporary Address Extensions for Stateless Address STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
Autoconfiguration in IPv6", RFC 8981, <https://www.rfc-editor.org/info/rfc9293>.
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[I-D.ietf-6man-rfc4941bis] 8.2. Informative References
Gont, F., Krishnan, S., Narten, T., and R. P. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", Work in Progress, Internet-
Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc4941bis-12.txt>.
[I-D.gont-opsec-ipv6-host-scanning] [Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Solutions", April 1997,
Networks", Work in Progress, Internet-Draft, draft-gont- <http://www.openbsd.org/advisories/sni_12_resolverid.txt>.
opsec-ipv6-host-scanning-02, 22 October 2012,
<https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-
host-scanning-02.txt>.
[I-D.ietf-opsec-ipv6-host-scanning] [Bellovin1989]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Bellovin, S., "Security Problems in the TCP/IP Protocol
Networks", Work in Progress, Internet-Draft, draft-ietf- Suite", Computer Communications Review, vol. 19, no. 2,
opsec-ipv6-host-scanning-08, 28 August 2015, pp. 32-48, April 1989,
<https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6- <https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.
host-scanning-08.txt>.
[I-D.gont-6man-stable-privacy-addresses] [Bellovin2002]
Gont, F., "A method for Generating Stable Privacy-Enhanced Bellovin, S., "A Technique for Counting NATted Hosts",
Addresses with IPv6 Stateless Address Autoconfiguration IMW'02, Marseille, France, DOI 10.1145/637201.637243,
(SLAAC)", Work in Progress, Internet-Draft, draft-gont- November 2002,
6man-stable-privacy-addresses-01, 31 March 2012, <https://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
<https://www.ietf.org/archive/id/draft-gont-6man-stable-
privacy-addresses-01.txt>.
[I-D.ietf-6man-stable-privacy-addresses] [CERT2001] CERT/CC, "CERT Advisory CA-2001-09: Statistical Weaknesses
Gont, F., "A Method for Generating Semantically Opaque in TCP/IP Initial Sequence Numbers", May 2001,
Interface Identifiers with IPv6 Stateless Address <https://resources.sei.cmu.edu/asset_files/
Autoconfiguration (SLAAC)", Work in Progress, Internet- WhitePaper/2001_019_001_496192.pdf>.
Draft, draft-ietf-6man-stable-privacy-addresses-17, 27
January 2014, <https://www.ietf.org/archive/id/draft-ietf-
6man-stable-privacy-addresses-17.txt>.
[I-D.cooper-6man-ipv6-address-generation-privacy] [draft-cooper-6man-ipv6-address-generation-privacy-00]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
Work in Progress, Internet-Draft, draft-cooper-6man-ipv6- Work in Progress, Internet-Draft, draft-cooper-6man-ipv6-
address-generation-privacy-00, 15 July 2013, address-generation-privacy-00, 15 July 2013,
<https://www.ietf.org/archive/id/draft-cooper-6man-ipv6- <https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-
address-generation-privacy-00.txt>. address-generation-privacy-00.txt>.
[I-D.ietf-6man-ipv6-address-generation-privacy] [draft-eddy-rfc793bis-04]
Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Eddy, W., Ed., "Transmission Control Protocol
Considerations for IPv6 Address Generation Mechanisms", Specification", Work in Progress, Internet-Draft, draft-
Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- eddy-rfc793bis-04, 25 August 2014,
address-generation-privacy-08, 23 September 2015, <https://www.ietf.org/archive/id/draft-eddy-rfc793bis-
<https://www.ietf.org/archive/id/draft-ietf-6man-ipv6- 04.txt>.
address-generation-privacy-08.txt>.
[Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit [draft-fgont-6man-rfc4941bis-00]
(help wanted!)", Message posted to the IPv6 Hackers Gont, F., Krishnan, S., Narten, T., and R. Draves,
mailing-list Message-ID: "Privacy Extensions for Stateless Address
<51184548.3030105@si6networks.com>, 2013, Autoconfiguration in IPv6", Work in Progress, Internet-
<https://lists.si6networks.com/pipermail/ Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018,
ipv6hackers/2013-February/000947.html>. <https://www.ietf.org/archive/id/draft-fgont-6man-
rfc4941bis-00.txt>.
[IPv6-Toolkit] [draft-gont-6man-address-usage-recommendations-00]
SI6 Networks, "SI6 Networks' IPv6 Toolkit", Gont, F. and W. LIU, "IPv6 Address Usage Recommendations",
<https://www.si6networks.com/tools/ipv6toolkit>. Work in Progress, Internet-Draft, draft-gont-6man-address-
usage-recommendations-00, 27 May 2016,
<https://www.ietf.org/archive/id/draft-gont-6man-address-
usage-recommendations-00.txt>.
[draft-gont-6man-non-stable-iids-00]
Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
Interface Identifiers", Work in Progress, Internet-Draft,
draft-gont-6man-non-stable-iids-00, 23 May 2016,
<https://www.ietf.org/archive/id/draft-gont-6man-non-
stable-iids-00.txt>.
[draft-gont-6man-predictable-fragment-id-00]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-gont-6man-predictable-fragment-id-00, 15 December
2011, <https://www.ietf.org/archive/id/draft-gont-6man-
predictable-fragment-id-00.txt>.
[draft-gont-6man-predictable-fragment-id-03]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-gont-6man-predictable-fragment-id-03, 9 January
2013, <https://www.ietf.org/archive/id/draft-gont-6man-
predictable-fragment-id-03.txt>.
[draft-gont-6man-stable-privacy-addresses-00] [draft-gont-6man-stable-privacy-addresses-00]
Gont, F., "A method for Generating Stable Privacy-Enhanced Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", Work in Progress, Internet-Draft, draft-gont- (SLAAC)", Work in Progress, Internet-Draft, draft-gont-
6man-stable-privacy-addresses-00, 15 December 2011, 6man-stable-privacy-addresses-00, 15 December 2011,
<https://tools.ietf.org/id/draft-gont-6man-stable-privacy- <https://www.ietf.org/archive/id/draft-gont-6man-stable-
addresses-00.txt>. privacy-addresses-00.txt>.
[draft-ietf-6man-stable-privacy-addresses-00] [draft-gont-6man-stable-privacy-addresses-01]
Gont, F., "A method for Generating Stable Privacy-Enhanced Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", Work in Progress, Internet-Draft, draft-ietf- (SLAAC)", Work in Progress, Internet-Draft, draft-gont-
6man-stable-privacy-addresses-00, 18 May 2012, 6man-stable-privacy-addresses-01, 31 March 2012,
<https://tools.ietf.org/id/draft-ietf-6man-stable-privacy- <https://www.ietf.org/archive/id/draft-gont-6man-stable-
addresses-00.txt>. privacy-addresses-01.txt>.
[draft-gont-6man-address-usage-recommendations-00] [draft-gont-ntp-port-randomization-00]
Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", Gont, F. and G. Gont, "Port Randomization in the Network
Work in Progress, Internet-Draft, draft-gont-6man-address- Time Protocol Version 4", Work in Progress, Internet-
usage-recommendations-00, 27 May 2016, Draft, draft-gont-ntp-port-randomization-00, 16 April
<https://tools.ietf.org/id/draft-gont-6man-address-usage- 2019, <https://www.ietf.org/archive/id/draft-gont-ntp-
recommendations-00.txt>. port-randomization-00.txt>.
[draft-gont-6man-non-stable-iids-00] [draft-gont-opsec-ipv6-host-scanning-02]
Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Interface Identifiers", Work in Progress, Internet-Draft, Networks", Work in Progress, Internet-Draft, draft-gont-
draft-gont-6man-non-stable-iids-00, 23 May 2016, opsec-ipv6-host-scanning-02, 23 October 2012,
<https://tools.ietf.org/id/draft-gont-6man-non-stable- <https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-
iids-00.txt>. host-scanning-02.txt>.
[draft-gont-predictable-numeric-ids-03]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
Work in Progress, Internet-Draft, draft-gont-predictable-
numeric-ids-03, 11 March 2019,
<https://datatracker.ietf.org/doc/html/draft-gont-
predictable-numeric-ids-03>.
[draft-ietf-6man-default-iids-00] [draft-ietf-6man-default-iids-00]
Gont, F., Cooper, A., Thaler, D., and W. Liu, Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
Work in Progress, Internet-Draft, draft-ietf-6man-default- Work in Progress, Internet-Draft, draft-ietf-6man-default-
iids-00, 28 July 2014, <https://tools.ietf.org/id/draft- iids-00, 24 January 2014,
ietf-6man-default-iids-00.txt>. <https://www.ietf.org/archive/id/draft-ietf-6man-default-
iids-00.txt>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [draft-ietf-6man-default-iids-16]
Gont, F., Cooper, A., Thaler, D., and W. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, Work in Progress, Internet-Draft, draft-ietf-6man-default-
<https://www.rfc-editor.org/info/rfc8064>. iids-16, 28 September 2016,
<https://www.ietf.org/archive/id/draft-ietf-6man-default-
iids-16.txt>.
[draft-ietf-6man-ipv6-address-generation-privacy-08]
Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms",
Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
address-generation-privacy-08, 23 September 2015,
<https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-
address-generation-privacy-08.txt>.
[draft-ietf-6man-predictable-fragment-id-00]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-00, 22 March 2013,
<https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-00.txt>.
[draft-ietf-6man-predictable-fragment-id-01]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-01, 29 April 2014,
<https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-01.txt>.
[draft-ietf-6man-predictable-fragment-id-02]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-02, 19 December
2014, <https://datatracker.ietf.org/doc/html/draft-ietf-
6man-predictable-fragment-id-02>.
[draft-ietf-6man-predictable-fragment-id-08]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-08, 9 June 2015,
<https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-08.txt>.
[draft-ietf-6man-predictable-fragment-id-10]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-10, 9 October
2015, <https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-10.txt>.
[draft-ietf-6man-rfc2460bis-05]
Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Work in Progress, Internet-Draft,
draft-ietf-6man-rfc2460bis-05, 28 June 2016,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc2460bis-05.txt>.
[draft-ietf-6man-rfc2460bis-13]
Deering, S. and R. Hinden, "draft-ietf-6man-rfc2460bis-
13", Work in Progress, Internet-Draft, draft-ietf-6man-
rfc2460bis-13, 19 May 2017,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc2460bis-13.txt>.
[draft-ietf-6man-rfc4941bis-00] [draft-ietf-6man-rfc4941bis-00]
Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves, Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Privacy Extensions for Stateless Address "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", Work in Progress, Internet- Autoconfiguration in IPv6", Work in Progress, Internet-
Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018, Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018,
<https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis- <https://www.ietf.org/archive/id/draft-ietf-6man-
00.txt>. rfc4941bis-00.txt>.
[draft-fgont-6man-rfc4941bis-00] [draft-ietf-6man-rfc4941bis-12]
Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves, Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Privacy Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", Work in Progress, Internet- Autoconfiguration in IPv6", Work in Progress, Internet-
Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018, Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020,
<https://tools.ietf.org/id/draft-fgont-6man-rfc4941bis- <https://www.ietf.org/archive/id/draft-ietf-6man-
00.txt>. rfc4941bis-12.txt>.
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers",
Work in Progress, Internet-Draft, draft-ietf-6man-default-
iids-16, 28 September 2016,
<https://www.ietf.org/archive/id/draft-ietf-6man-default-
iids-16.txt>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [draft-ietf-6man-stable-privacy-addresses-00]
Considerations for IPv6 Address Generation Mechanisms", Gont, F., "A method for Generating Stable Privacy-Enhanced
RFC 7721, DOI 10.17487/RFC7721, March 2016, Addresses with IPv6 Stateless Address Autoconfiguration
<https://www.rfc-editor.org/info/rfc7721>. (SLAAC)", Work in Progress, Internet-Draft, draft-ietf-
6man-stable-privacy-addresses-00, 18 May 2012,
<https://www.ietf.org/archive/id/draft-ietf-6man-stable-
privacy-addresses-00.txt>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 [draft-ietf-6man-stable-privacy-addresses-17]
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, Gont, F., "A Method for Generating Semantically Opaque
<https://www.rfc-editor.org/info/rfc7707>. Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", Work in Progress, Internet-
Draft, draft-ietf-6man-stable-privacy-addresses-17, 27
January 2014, <https://www.ietf.org/archive/id/draft-ietf-
6man-stable-privacy-addresses-17.txt>.
[I-D.gont-predictable-numeric-ids] [draft-ietf-ntp-port-randomization-00]
Gont, F. and I. Arce, "Security and Privacy Implications Gont, F., Gont, G., and M. Lichvar, "Port Randomization in
of Numeric Identifiers Employed in Network Protocols", the Network Time Protocol Version 4", Work in Progress,
Work in Progress, Internet-Draft, draft-gont-predictable- Internet-Draft, draft-ietf-ntp-port-randomization-00, 22
numeric-ids-03, 11 March 2019, October 2019, <https://www.ietf.org/archive/id/draft-ietf-
<https://www.ietf.org/archive/id/draft-gont-predictable- ntp-port-randomization-00.txt>.
numeric-ids-03.txt>.
[I-D.gont-numeric-ids-sec-considerations] [draft-ietf-ntp-port-randomization-08]
Gont, F. and I. Arce, "Security Considerations for Gont, F., Gont, G., and M. Lichvar, "Port Randomization in
Transient Numeric Identifiers Employed in Network the Network Time Protocol Version 4", Work in Progress,
Protocols", Work in Progress, Internet-Draft, draft-gont- Internet-Draft, draft-ietf-ntp-port-randomization-00, 10
numeric-ids-sec-considerations-08, 10 December 2022, June 2021, <https://www.ietf.org/archive/id/draft-ietf-
<https://datatracker.ietf.org/api/v1/doc/document/draft- ntp-port-randomization-08.txt>.
gont-numeric-ids-sec-considerations/>.
[I-D.irtf-pearg-numeric-ids-generation] [draft-ietf-ntp-refid-updates-00]
Gont, F. and I. Arce, "On the Generation of Transient Stenn, H. and S. Goldberg, "Network Time Protocol REFID
Numeric Identifiers", Work in Progress, Internet-Draft, Updates", Work in Progress, Internet-Draft, draft-ietf-
draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022, ntp-refid-updates-00, 13 November 2016,
<https://www.ietf.org/archive/id/draft-irtf-pearg-numeric- <https://www.ietf.org/archive/id/draft-ietf-ntp-refid-
ids-generation-11.txt>. updates-00.txt>.
[I-D.ietf-6man-rfc2460bis] [draft-ietf-opsec-ipv6-host-scanning-08]
Deering, S. E. and R. M. Hinden, "Internet Protocol, Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Version 6 (IPv6) Specification", Work in Progress, Networks", Work in Progress, Internet-Draft, draft-ietf-
Internet-Draft, draft-ietf-6man-rfc2460bis-13, 19 May opsec-ipv6-host-scanning-08, 28 August 2015,
2017, <https://www.ietf.org/archive/id/draft-ietf-6man- <https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-
rfc2460bis-13.txt>. host-scanning-08.txt>.
[draft-stenn-ntp-not-you-refid-00] [draft-stenn-ntp-not-you-refid-00]
Goldberg, S. and H. Stenn, "Network Time Protocol Not You Goldberg, S. and H. Stenn, "Network Time Protocol Not You
REFID", Work in Progress, Internet-Draft, draft-stenn-ntp- REFID", Work in Progress, Internet-Draft, draft-stenn-ntp-
not-you-refid-00, 8 July 2016, <https://tools.ietf.org/id/ not-you-refid-00, 8 July 2016,
draft-stenn-ntp-not-you-refid-00.txt>. <https://www.ietf.org/archive/id/draft-stenn-ntp-not-you-
refid-00.txt>.
[draft-ietf-ntp-refid-updates-00] [Economou2010]
Goldberg, S. and H. Stenn, "Network Time Protocol Not You Economou, N., "Windows SMTP Service DNS query Id
REFID", Work in Progress, Internet-Draft, draft-ietf-ntp- vulnerabilities", Advisory ID Internal CORE-2010-0427, May
refid-updates-00, 13 November 2016, 2010, <https://www.coresecurity.com/core-labs/advisories/
<https://tools.ietf.org/id/draft-ietf-ntp-refid-updates- core-2010-0424-windows-smtp-dns-query-id-bugs>.
00.txt>.
[Fyodor2002]
Fyodor, "Idle scanning and related IP ID games", September
2002,
<https://nmap.org/presentations/CanSecWest03/CD_Content/
idlescan_paper/idlescan.html>.
[Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- [Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
05", Post to the NTP WG mailing list Message-ID: 05", message to the IETF NTP mailing list, 16 April 2019,
<d871d66d-4043-d8d0-f924-2191ebb2e2ce@si6networks.com>, 16 <https://mailarchive.ietf.org/arch/msg/ntp/
April 2019, <https://mailarchive.ietf.org/arch/msg/ntp/
NkfTHxUUOdp14Agh3h1IPqfcRRg>. NkfTHxUUOdp14Agh3h1IPqfcRRg>.
[I-D.ietf-ntp-refid-updates] [Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack
Stenn, H. and S. Goldberg, "Network Time Protocol REFID In Paris 2011 Conference, Paris, France, June 2011,
Updates", Work in Progress, Internet-Draft, draft-ietf- <https://www.si6networks.com/files/presentations/hip2011/
ntp-refid-updates-05, 25 March 2019, fgont-hip2011-hacking-ipv6-networks.pdf>.
<https://www.ietf.org/archive/id/draft-ietf-ntp-refid-
updates-05.txt>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
"Network Time Protocol Version 4: Protocol and Algorithms Conference, Ottawa, Canada, May 2012,
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.si6networks.com/files/presentations/
<https://www.rfc-editor.org/info/rfc5905>. bsdcan2012/fgont-bsdcan2012-recent-advances-in-
ipv6-security.pdf>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May (help wanted!)", message to the IPv6 Hackers mailing list,
2014, <https://www.rfc-editor.org/info/rfc7258>. 11 February 2013,
<https://lists.si6networks.com/pipermail/
ipv6hackers/2013-February/000947.html>.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [IANA-PROT]
RFC 1948, DOI 10.17487/RFC1948, May 1996, IANA, "Protocol Registries",
<https://www.rfc-editor.org/info/rfc1948>. <https://www.iana.org/protocols>.
[Wright1994] [IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and
Wright, G.R. and W.R. Stevens, "TCP/IP Illustrated, Volume KASLR Bypass (Extended Version)",
2: The Implementation", Addison-Wesley, 1994. DOI 10.48550/arXiv.1906.10478, October 2019,
<https://arxiv.org/pdf/1906.10478.pdf>.
[Zalewski2001] [IPv6-Toolkit]
Zalewski, M., "Strange Attractors and TCP/IP Sequence SI6 Networks, "IPv6 Toolkit",
Number Analysis", 2001, <https://www.si6networks.com/tools/ipv6toolkit>.
<https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.
[Zalewski2002] [Kaminsky2008]
Zalewski, M., "Strange Attractors and TCP/IP Sequence Kaminsky, D., "Black Ops 2008: It's The End Of The Cache
Number Analysis - One Year Later", 2001, As We Know It", August 2008,
<https://lcamtuf.coredump.cx/newtcp/>. <https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-
Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf>.
[Bellovin1989] [Klein2007]
Bellovin, S., "Security Problems in the TCP/IP Protocol Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Suite", Computer Communications Review, vol. 19, no. 2, Predictable IP ID Vulnerability", October 2007,
pp. 32-48, 1989, <https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
<https://www.cs.columbia.edu/~smb/papers/ipext.pdf>. DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>.
[Klein2007b]
Klein, A., "BIND 9 DNS Cache Poisoning", March 2007,
<https://citeseerx.ist.psu.edu/doc/10.1.1.86.4474>.
[Klein2007c]
Klein, A., "Windows DNS Server Cache Poisoning", March
2007, <https://dl.packetstormsecurity.net/papers/attack/
Windows_DNS_Cache_Poisoning.pdf>.
[Morbitzer2013]
Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", message to
the nmap-dev mailing list, 3 June 2013,
<https://seclists.org/nmap-dev/2013/q2/394>.
[Morris1985] [Morris1985]
Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
NJ, 1985, NJ, February 1985,
<https://pdos.csail.mit.edu/~rtm/papers/117.pdf>. <https://pdos.csail.mit.edu/~rtm/papers/117.pdf>.
[USCERT2001] [NIST-NTP] Sherman, J. and J. Levine, "Usage Analysis of the NIST
US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple Internet Time Service", Journal of Research of the
TCP/IP implementations may use statistically predictable National Institute of Standards and Technology, Volume
initial sequence numbers", 2001, 121, March 2016,
<https://www.kb.cert.org/vuls/id/498440>. <https://tf.nist.gov/general/pdf/2818.pdf>.
[CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in [NTP-PORTR]
TCP/IP Initial Sequence Numbers", 2001, Gont, F., "[Ntp] New rev of the NTP port randomization I-D
<https://resources.sei.cmu.edu/asset_files/ (Fwd: New Version Notification for draft-gont-ntp-port-
WhitePaper/2001_019_001_496192.pdf>. randomization-01.txt)", message to the IETF NTP mailing
list, 21 May 2019,
<https://mailarchive.ietf.org/arch/msg/ntp/
xSCu5Vhb3zoWcqEjUMmzP8pOdW4/>.
[Shimomura1995] [OpenBSD-IPv4-ID]
Shimomura, T., "Technical details of the attack described OpenBSD, "Randomization of the IPv4 Identification field",
by Markoff in NYT", Message posted in USENET's December 1998,
comp.security.misc newsgroup Message-ID: <https://cvsweb.openbsd.org/src/sys/netinet/
<3g5gkl$5j1@ariel.sdsc.edu>, 1995, ip_id.c?rev=1.1>.
<https://www.gont.com.ar/docs/post-shimomura-usenet.txt>.
[I-D.eddy-rfc793bis-04] [OpenBSD-IPv6-ID]
Eddy, W., "Transmission Control Protocol Specification", OpenBSD, "Randomization of the IPv6 Identification field",
Work in Progress, Internet-Draft, draft-eddy-rfc793bis-04, October 2003,
25 August 2014, <https://cvsweb.openbsd.org/src/sys/netinet6/
<https://tools.ietf.org/id/draft-eddy-rfc793bis-04.txt>. ip6_id.c?rev=1.1>.
[OpenBSD-PR]
OpenBSD, "Implementation of port randomization", July
1996, <https://cvsweb.openbsd.org/src/sys/netinet/
in_pcb.c?rev=1.6>.
[OpenBSD-TCP-ISN-H]
OpenBSD, "Implementation of RFC1948 for TCP ISN
randomization", June 2007,
<https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.97>.
[OpenBSD-TCP-ISN-I] [OpenBSD-TCP-ISN-I]
OpenBSD, "Implementation of TCP ISN randomization based on OpenBSD, "Implementation of TCP ISN randomization based on
random increments", 29 July 1996, random increments", July 1996,
<https://cvsweb.openbsd.org/src/sys/netinet/ <https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.6>. tcp_subr.c?rev=1.6>.
[OpenBSD-TCP-ISN-R] [OpenBSD-TCP-ISN-R]
OpenBSD, "Implementation of TCP ISN randomization based on OpenBSD, "Implementation of TCP ISN randomization based on
simple randomization", 13 December 2000, simple randomization", December 2000,
<https://cvsweb.openbsd.org/src/sys/netinet/ <https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.37>. tcp_subr.c?rev=1.37>.
[OpenBSD-TCP-ISN-H] [RedHat2011]
OpenBSD, "Implementation of RFC1948 for TCP ISN Red Hat, "RHSA-2011:1465-1 - Security Advisory", November
randomization", 13 December 2000, 2011, <https://rhn.redhat.com/errata/RHSA-2011-1465.html>.
<https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.97>.
[I-D.gont-ntp-port-randomization]
Gont, F. and G. Gont, "Port Randomization in the Network
Time Protocol Version 4", Work in Progress, Internet-
Draft, draft-gont-ntp-port-randomization-04, 6 August
2019, <https://www.ietf.org/archive/id/draft-gont-ntp-
port-randomization-04.txt>.
[I-D.ietf-ntp-port-randomization]
Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
Version 4: Port Randomization", Work in Progress,
Internet-Draft, draft-ietf-ntp-port-randomization-08, 10
June 2021, <https://www.ietf.org/archive/id/draft-ietf-
ntp-port-randomization-08.txt>.
[RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
Version 4: Port Randomization", RFC 9109,
DOI 10.17487/RFC9109, August 2021,
<https://www.rfc-editor.org/info/rfc9109>.
[NTP-PORTR]
Gont, F., "[Ntp] New rev of the NTP port randomization I-D
(Fwd: New Version Notification for draft-gont-ntp-port-
randomization-01.txt)", 2019,
<https://mailarchive.ietf.org/arch/browse/
ntp/?gbt=1&index=n09Sb61WkH03lSRtamkELXwEQN4>.
[NIST-NTP] Sherman, J.A. and J. Levine, "Usage Analysis of the NIST
Internet Time Service", Journal of Research of the
National Institute of Standards and Technology Volume 121,
8 March 2016, <https://tf.nist.gov/general/pdf/2818.pdf>.
[IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and
KASLR Bypass (Extended Version)", June 2019,
<https://arxiv.org/pdf/1906.10478.pdf>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, DOI 10.17487/RFC1948, May 1996,
<https://www.rfc-editor.org/info/rfc1948>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, DOI 10.17487/RFC5157, March 2008,
<https://www.rfc-editor.org/info/rfc5157>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
<https://www.rfc-editor.org/info/rfc6274>. <https://www.rfc-editor.org/info/rfc6274>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739, Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>. February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[Bellovin2002] [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
Bellovin, S. M., "A Technique for Counting NATted Hosts", "Recommendation on Stable IPv6 Interface Identifiers",
IMW'02 Nov. 6-8, 2002, Marseille, France, 2002, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.cs.columbia.edu/~smb/papers/fnat.pdf>. <https://www.rfc-editor.org/info/rfc8064>.
[Fyodor2002] [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
Fyodor, "Idle scanning and related IP ID games", 2002, "Temporary Address Extensions for Stateless Address
<http://www.insecure.org/nmap/idlescan.html>. Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
Version 4: Port Randomization", RFC 9109,
DOI 10.17487/RFC9109, August 2021,
<https://www.rfc-editor.org/info/rfc9109>.
[RFC9415] Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July
2023, <https://www.rfc-editor.org/info/rfc9415>.
[RFC9416] Gont, F. and I. Arce, "Security Considerations for
Transient Numeric Identifiers Employed in Network
Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July
2023, <https://www.rfc-editor.org/info/rfc9416>.
[Sacramento2002]
Sacramento, V., "CAIS-ALERT: Vulnerability in the sending
requests control of BIND", message to the Bugtraq mailing
list, 25 November 2002,
<https://seclists.org/bugtraq/2002/Nov/331>.
[Sanfilippo1998a] [Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", Post to Bugtraq Sanfilippo, S., "about the ip header id", message to the
mailing-list, Mon Dec 14 1998, Bugtraq mailing list, 14 December 1998,
<http://seclists.org/bugtraq/1998/Dec/48>. <http://seclists.org/bugtraq/1998/Dec/48>.
[Sanfilippo1998b] [Sanfilippo1998b]
Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, Sanfilippo, S., "new tcp scan method", message to the
1998, <https://github.com/antirez/hping/raw/master/docs/ Bugtraq mailing list, 18 December 1998,
SPOOFED_SCAN.txt>. <https://seclists.org/bugtraq/1998/Dec/79>.
[Sanfilippo1999] [Sanfilippo1999]
Sanfilippo, S., "more ip id", Post to Bugtraq mailing- Sanfilippo, S., "more ip id", message to the Bugtraq
list, 1999, mailing list, November 1999,
<https://github.com/antirez/hping/raw/master/docs/MORE- <https://github.com/antirez/hping/raw/master/docs/MORE-
FUN-WITH-IPID>. FUN-WITH-IPID>.
[Morbitzer2013] [Schuba1993]
Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message Schuba, C., "Addressing Weakness in the Domain Name System
posted to the nmap-dev mailing-list, 2013, Protocol", August 1993,
<https://seclists.org/nmap-dev/2013/q2/394>. <http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/
schuba-DNS-msthesis.pdf>.
[OpenBSD-IPv4-ID]
OpenBSD, "Randomization of the IPv4 Identification field",
26 December 1998,
<https://cvsweb.openbsd.org/src/sys/netinet/
ip_id.c?rev=1.1>.
[OpenBSD-IPv6-ID] [Shimomura1995]
OpenBSD, "Randomization of the IPv6 Identification field", Shimomura, T., "Technical details of the attack described
1 October 2003, by Markoff in NYT", message to the USENET
<https://cvsweb.openbsd.org/src/sys/netinet6/ comp.security.misc newsgroup, 25 January 1995,
ip6_id.c?rev=1.1>. <https://www.gont.com.ar/files/post-shimomura-usenet.txt>.
[Silbersack2005] [Silbersack2005]
Silbersack, M.J., "Improving TCP/IP security through Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability", randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference, 2005, EuroBSDCon 2005 Conference, January 2005,
<https://citeseerx.ist.psu.edu/viewdoc/ <https://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.91.4542&rep=rep1&type=pdf>. download?doi=10.1.1.91.4542&rep=rep1&type=pdf>.
[Zalewski2003] [SUSE2011] Meissner, M., "[security-announce] SUSE Security
Zalewski, M., "A new TCP/IP blind data injection Announcement: Linux kernel security update (SUSE-
technique?", 2003, SA:2011:046)", message to the openSUSE Security Announce
<https://lcamtuf.coredump.cx/ipfrag.txt>. mailing list, 13 December 2011,
[Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and
Solutions", 1997,
<http://www.openbsd.org/advisories/sni_12_resolverid.txt>.
[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", 2007,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>.
[Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack
In Paris 2011 Conference Paris, France, June 2011.
[RedHat2011]
RedHat, "RedHat Security Advisory RHSA-2011:1465-1:
Important: kernel security and bug fix update", 2011,
<https://rhn.redhat.com/errata/RHSA-2011-1465.html>.
[Ubuntu2011]
Ubuntu, "Ubuntu: USN-1253-1: Linux kernel
vulnerabilities", 2011,
<https://ubuntu.com/security/notices/USN-1253-1>.
[SUSE2011] SUSE, "SUSE Security Announcement: Linux kernel security
update (SUSE-SA:2011:046)", 2011,
<https://lists.opensuse.org/opensuse-security- <https://lists.opensuse.org/opensuse-security-
announce/2011-12/msg00011.html>. announce/2011-12/msg00011.html>.
[Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 [TCPT-uptime]
Conference Ottawa, Canada. May 11-12, 2012, May 2012, McDanel, B., "TCP Timestamping - Obtaining System Uptime
<https://www.si6networks.com/files/presentations/ Remotely", message to the Bugtraq mailing list, March
bsdcan2012/fgont-bsdcan2012-recent-advances-in- 2001, <https://seclists.org/bugtraq/2001/Mar/182>.
ipv6-security.pdf>.
[I-D.gont-6man-predictable-fragment-id] [Ubuntu2011]
Gont, F., "Security Implications of Predictable Fragment Ubuntu, "USN-1253-1: Linux kernel vulnerabilities",
Identification Values", Work in Progress, Internet-Draft, November 2011,
draft-gont-6man-predictable-fragment-id-03, 9 January <https://ubuntu.com/security/notices/USN-1253-1>.
2013, <https://www.ietf.org/archive/id/draft-gont-6man-
predictable-fragment-id-03.txt>.
[I-D.ietf-6man-predictable-fragment-id] [USCERT2001]
Gont, F., "Security Implications of Predictable Fragment CERT CC, "Multiple TCP/IP implementations may use
Identification Values", Work in Progress, Internet-Draft, statistically predictable initial sequence numbers",
draft-ietf-6man-predictable-fragment-id-10, 9 October Vulnerability Note VU#498440, March 2001,
2015, <https://www.ietf.org/archive/id/draft-ietf-6man- <https://www.kb.cert.org/vuls/id/498440>.
predictable-fragment-id-10.txt>.
[draft-ietf-6man-predictable-fragment-id-01] [Vixie1995]
Gont, F., "Security Implications of Predictable Fragment Vixie, P., "DNS and BIND Security Issues", 5th Usenix
Identification Values", Work in Progress, Internet-Draft, Security Symposium, June 1995, <https://www.usenix.org/leg
draft-ietf-6man-predictable-fragment-id-01, 30 April 2014, acy/publications/library/proceedings/security95/
<https://tools.ietf.org/id/draft-ietf-6man-predictable- full_papers/vixie.pdf>.
fragment-id-01.txt>.
[draft-ietf-6man-predictable-fragment-id-02] [VU-800113]
Gont, F., "Security Implications of Predictable Fragment CERT/CC, "Multiple DNS implementations vulnerable to cache
Identification Values", Work in Progress, Internet-Draft, poisoning", Vulnerability Note VU#800113, July 2008,
draft-ietf-6man-predictable-fragment-id-02, 19 December <https://www.kb.cert.org/vuls/id/800113>.
2014, <https://tools.ietf.org/id/draft-ietf-6man-
predictable-fragment-id-02.txt>.
[draft-gont-6man-predictable-fragment-id-00] [Wright1994]
Gont, F., "Security Implications of Predictable Fragment Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
Identification Values", Work in Progress, Internet-Draft, The Implementation", Addison-Wesley, February 1995.
draft-gont-6man-predictable-fragment-id-00, 15 December
2011, <https://tools.ietf.org/id/draft-gont-6man-
predictable-fragment-id-00.txt>.
[draft-ietf-6man-predictable-fragment-id-00] [Zalewski2001]
Gont, F., "Security Implications of Predictable Fragment Zalewski, M., "Strange Attractors and TCP/IP Sequence
Identification Values", Work in Progress, Internet-Draft, Number Analysis (2001)", March 2001,
draft-ietf-6man-predictable-fragment-id-00, 22 March 2013, <https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.
<https://tools.ietf.org/id/draft-ietf-6man-predictable-
fragment-id-00.txt>.
[draft-ietf-6man-predictable-fragment-id-08] [Zalewski2002]
Gont, F., "Security Implications of Predictable Fragment Zalewski, M., "Strange Attractors and TCP/IP Sequence
Identification Values", Work in Progress, Internet-Draft, Number Analysis - One Year Later (2002)", 2002,
draft-ietf-6man-predictable-fragment-id-08, 9 June 2015, <https://lcamtuf.coredump.cx/newtcp/>.
<https://tools.ietf.org/id/draft-ietf-6man-predictable-
fragment-id-08.txt>.
[Schuba1993] [Zalewski2003]
Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME Zalewski, M., "A new TCP/IP blind data injection
SYSTEM PROTOCOL", 1993, technique?", December 2003,
<http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/ <https://lcamtuf.coredump.cx/ipfrag.txt>.
schuba-DNS-msthesis.pdf>.
[Vixie1995] Acknowledgements
Vixie, P., "DNS and BIND Security Issues", 5th Usenix
Security Symposium May 2, 1995, 2 May 1995, <https://www.u
senix.org/legacy/publications/library/proceedings/
security95/full_papers/vixie.pdf>.
[Klein2007b] The authors would like to thank (in alphabetical order) Bernard
Klein, A., "BIND 9 DNS Cache Poisoning", March 2007, Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson,
<https://citeseerx.ist.psu.edu/viewdoc/ Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris
summary?doi=10.1.1.86.4474>. Shrishak, Joe Touch, Brian Trammell, and Christopher Wood for
providing valuable comments on earlier versions of this document.
[Klein2007c] The authors would like to thank (in alphabetical order) Steven
Klein, A., "Windows DNS Server Cache Poisoning", March Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson for
2007, <https://dl.packetstormsecurity.net/papers/attack/ providing valuable comments on
Windows_DNS_Cache_Poisoning.pdf>. [draft-gont-predictable-numeric-ids-03], on which this document is
based.
[Sacramento2002] Section 4.2 of this document borrows text from [RFC6528], authored by
Sacramento, V., "CAIS-ALERT: Vulnerability in the sending Fernando Gont and Steven Bellovin.
requests control of BIND", 19 November 2002,
<https://seclists.org/bugtraq/2002/Nov/331>.
[Kaminsky2008] The authors would like to thank Sara Dickinson and Christopher Wood
Kaminsky, D., "Black Ops 2008: It's The End Of The Cache for their guidance during the publication process of this document.
As We Know It", August 2008,
<https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-
Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf>.
[Economou2010] The authors would like to thank Diego Armando Maradona for his magic
Economou, N., "Windows SMTP Service DNS query Id and inspiration.
vulnerabilities", Advisory ID Internal CORE-2010-0427 May
4, 2010, 4 May 2010, <https://www.coresecurity.com/core-
labs/advisories/core-2010-0424-windows-smtp-dns-query-id-
bugs>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
Segurola y Habana 4310 7mo piso Segurola y Habana
4310 7mo piso
Ciudad Autonoma de Buenos Aires Ciudad Autonoma de Buenos Aires
Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Ivan Arce Ivan Arce
Quarkslab Quarkslab
Segurola y Habana 4310 7mo piso Segurola y Habana
4310 7mo piso
Ciudad Autonoma de Buenos Aires Ciudad Autonoma de Buenos Aires
Buenos Aires
Argentina Argentina
Email: iarce@quarkslab.com Email: iarce@quarkslab.com
URI: https://www.quarkslab.com URI: https://www.quarkslab.com
 End of changes. 241 change blocks. 
925 lines changed or deleted 968 lines changed or added

This html diff was produced by rfcdiff 1.48.