rfc9416.original   rfc9416.txt 
Network Working Group F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft SI6 Networks Request for Comments: 9416 SI6 Networks
Updates: 3552 (if approved) I. Arce BCP: 72 I. Arce
Intended status: Best Current Practice Quarkslab Updates: 3552 Quarkslab
Expires: 31 July 2023 27 January 2023 Category: Best Current Practice July 2023
ISSN: 2070-1721
Security Considerations for Transient Numeric Identifiers Employed in Security Considerations for Transient Numeric Identifiers Employed in
Network Protocols Network Protocols
draft-gont-numeric-ids-sec-considerations-11
Abstract Abstract
Poor selection of transient numerical identifiers in protocols such Poor selection of transient numerical identifiers in protocols such
as the TCP/IP suite has historically led to a number of attacks on as the TCP/IP suite has historically led to a number of attacks on
implementations, ranging from Denial of Service (DoS) to data implementations, ranging from Denial of Service (DoS) or data
injection and information leakage that can be exploited by pervasive injection to information leakages that can be exploited by pervasive
monitoring. Due diligence in the specification of transient numeric monitoring. Due diligence in the specification of transient numeric
identifiers is required even when cryptographic techniques are identifiers is required even when cryptographic techniques are
employed, since these techniques might not mitigate all the employed, since these techniques might not mitigate all the
associated issues. This document formally updates RFC 3552, associated issues. This document formally updates RFC 3552,
incorporating requirements for transient numeric identifiers, to incorporating requirements for transient numeric identifiers, to
prevent flaws in future protocols and implementations. prevent flaws in future protocols and implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
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 Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 31 July 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/rfc9416.
Copyright Notice Copyright Notice
Copyright (c) 2023 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. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Issues with the Specification of Transient Numeric 3. Issues with the Specification of Transient Numeric Identifiers
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 4. Common Flaws in the Generation of Transient Numeric Identifiers
4. Common Flaws in the Generation of Transient Numeric 5. Requirements for Transient Numeric Identifiers
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations
5. Requirements for Transient Numeric Identifiers . . . . . . . 7 7. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Network protocols employ a variety of transient numeric identifiers Networking protocols employ a variety of transient numeric
for different protocol entities, ranging from DNS Transaction IDs identifiers for different protocol objects, such as IPv4 and IPv6
(TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6 Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers
Interface Identifiers (IIDs). These identifiers usually have (IIDs) [RFC4291], transport-protocol ephemeral port numbers
specific properties that must be satisfied such that they do not [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC9293], NTP
result in negative interoperability implications (e.g., uniqueness Reference IDs (REFIDs) [RFC5905], and DNS IDs [RFC1035]. These
during a specified period of time), and an associated failure identifiers typically have specific requirements (e.g., uniqueness
severity when such properties are not met. during a specified period of time) that must be satisfied such that
they do not result in negative interoperability implications, and an
associated failure severity when such requirements are not met
[RFC9415].
The TCP/IP protocol suite alone has been subject to variety of | NOTE: Some documents refer to the DNS ID as the DNS "Query ID"
attacks on its transient numeric identifiers over the past 30 years | or "TxID".
or more, with effects ranging from Denial of Service (DoS) or data
injection, to information leakage that could be exploited for For more than 30 years, a large number of implementations of IETF
pervasive monitoring [RFC7258]. The root of these issues has been, protocols have been subject to a variety of attacks, with effects
in many cases, the poor selection of identifiers in such protocols, ranging from Denial of Service (DoS) or data injection to information
usually as a result of insufficient or misleading specifications. leakages that could be exploited for pervasive monitoring [RFC7258].
While it is generally trivial to identify an algorithm that can The root cause of these issues has been, in many cases, the poor
satisfy the interoperability requirements for a given identifier, selection of transient numeric identifiers in such protocols, usually
there exists practical evidence [I-D.irtf-pearg-numeric-ids-history] as a result of insufficient or misleading specifications. While it
that doing so without negatively affecting the security and/or is generally trivial to identify an algorithm that can satisfy the
privacy properties of the aforementioned protocols is prone to error. 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 [RFC9414].
For example, implementations have been subject to security and/or For example, implementations have been subject to security and/or
privacy issues resulting from: privacy issues resulting from:
* Predictable TCP sequence numbers (see e.g. [Morris1985], * predictable IPv4 or IPv6 Identification values (e.g., see
[Bellovin1989], and [RFC6528]) [Sanfilippo1998a], [RFC6274], and [RFC7739]),
* Predictable transport protocol numbers (see e.g. [Silbersack2005] * predictable IPv6 IIDs (e.g., see [RFC7217], [RFC7707], and
and [RFC6056]) [RFC7721]),
* Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. * predictable transport-protocol ephemeral port numbers (e.g., see
[Sanfilippo1998a], [RFC6274], and [RFC7739]) [RFC6056] and [Silbersack2005]),
* Predictable IPv6 IIDs (see e.g. [RFC7217], [RFC7707], and * predictable TCP Initial Sequence Numbers (ISNs) (e.g., see
[RFC7721]) [Morris1985], [Bellovin1989], and [RFC6528]),
* Predictable DNS TxIDs (see e.g. [Schuba1993] and [Klein2007]) * predictable initial timestamps in TCP timestamps options (e.g.,
see [TCPT-uptime] and [RFC7323]), and
Recent history indicates that when new protocols are standardized or * predictable DNS IDs (see, e.g., [Schuba1993] and [Klein2007]).
Recent history indicates that, when new protocols are standardized or
new protocol implementations are produced, the security and privacy new protocol implementations are produced, the security and privacy
properties of the associated identifiers tend to be overlooked and properties of the associated transient numeric identifiers tend to be
inappropriate algorithms to generate such identifiers are either overlooked, and inappropriate algorithms to generate such identifiers
suggested in the specification or selected by implementers. As a are either suggested in the specifications or selected by
result, advice in this area is warranted. implementers. As a result, advice in this area is warranted.
We note that the use of cryptographic techniques for confidentiality We note that the use of cryptographic techniques for confidentiality
and authentication might not eliminate all the issues associated with and authentication might not eliminate all the issues associated with
predictable transient numeric identifiers. Therefore, due diligence predictable transient numeric identifiers. Therefore, due diligence
in the specification of transient numeric identifiers is required in the specification of transient numeric identifiers is required
even when cryptographic techniques are employed. even when cryptographic techniques are employed.
Note: | NOTE: For example, cryptographic authentication can readily
For example, cryptographic authentication can readily mitigate | mitigate data injection attacks even in the presence of
data injection attacks even in the presence of predictable | predictable transient numeric identifiers (such as "sequence
transient numeric identifiers (such as "sequence numbers"). | numbers"). However, use of flawed algorithms (such as global
However, use of flawed algorithms (such as global counters) for | counters) for generating transient numeric identifiers could
generating transient numeric identifiers could still result in | still result in information leakages even when cryptographic
information leakages even when cryptographic techniques are | techniques are employed. These information leakages could in
employed. These information leakages could in turn be leveraged | turn be leveraged to perform other devastating attacks (please
to perform other devastating attacks (please see | see [RFC9415] for further details).
[I-D.irtf-pearg-numeric-ids-generation] for further details).
Section 3 provides an overview of common flaws in the specification Section 3 provides an overview of common flaws in the specification
of transient numeric identifiers. Section 4 provides an overview of of transient numeric identifiers. Section 4 provides an overview of
the implications of predictable transient numeric identifiers. common flaws in the generation of transient numeric identifiers and
Finally, Section 5 provides key guidelines for protocol designers. their associated security and privacy implications. Finally,
Section 5 provides key guidelines for protocol designers.
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.
Failure Severity: Failure Severity:
The interoperability consequences of a failure to comply with the The interoperability consequences of a failure to comply with the
interoperability requirements of a given identifier. Severity interoperability requirements of a given identifier. Severity
considers the worst potential consequence of a failure, determined considers the worst potential consequence of a failure, determined
by the system damage and/or time lost to repair the failure. In by the system damage and/or time lost to repair the failure. In
this document we define two types of failure severity: "soft" and this document, we define two types of failure severity: "soft" and
"hard". "hard".
Hard Failure:
A hard failure is a non-recoverable condition in which a protocol
does not operate in the prescribed manner or it operates with
excessive degradation of service. For example, an established TCP
connection that is aborted due to an error condition constitutes,
from the point of view of the transport protocol, a hard failure,
since it enters a state from which normal operation cannot be
recovered.
Soft Failure: Soft Failure:
A soft failure is a recoverable condition in which a protocol does A recoverable condition in which a protocol does not operate in
not operate in the prescribed manner but normal operation can be the prescribed manner but normal operation can be resumed
resumed automatically in a short period of time. For example, a automatically in a short period of time. For example, a simple
simple packet-loss event that is subsequently recovered with a packet-loss event that is subsequently recovered with a
retransmission can be considered a soft failure. retransmission can be considered a soft failure.
Hard Failure:
A non-recoverable condition in which a protocol does not operate
in the prescribed manner or it operates with excessive degradation
of service. For example, an established TCP connection that is
aborted due to an error condition constitutes, from the point of
view of the transport protocol, a hard failure, since it enters a
state from which normal operation cannot be recovered.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Issues with the Specification of Transient Numeric Identifiers 3. Issues with the Specification of Transient Numeric Identifiers
A recent survey of transient numeric identifier usage in protocol Recent work on transient numeric identifier usage in protocol
specifications and implementations specifications and implementations [RFC9414] [RFC9415] revealed that
[I-D.irtf-pearg-numeric-ids-history] revealed that most of the issues most of the issues discussed in this document arise as a result of
discussed in this document arise as a result of one of the following one of the following conditions:
conditions:
* Protocol specifications that under-specify the requirements for * protocol specifications that under specify their transient numeric
their identifiers identifiers
* Protocol specifications that over-specify their identifiers * protocol specifications that over specify their transient numeric
identifiers
* Protocol implementations that simply fail to comply with the * protocol implementations that simply fail to comply with the
specified requirements specified requirements
Both under-specifying and over-specifying identifiers is hazardous. Both under specifying and over specifying transient numeric
TCP port numbers and sequence numbers [RFC0793] and DNS TxID identifiers is hazardous. TCP local ports [RFC0793], as well as DNS
[RFC1035] were originally under-specified, leading to implementations IDs [RFC1035], were originally under specified, leading to
that used predictable values and thus were vulnerable to numerous implementations that resulted in predictable values and thus were
off-path attacks. Over-specification, as for IPv6 Interface vulnerable to numerous off-path attacks. Over specification, as for
Identifiers (IIDs) [RFC4291] and Fragment Identification values IPv6 Interface Identifiers (IIDs) [RFC4291] and IPv6 Identification
[RFC2460], left implementations unable to respond to security and values [RFC2460], left implementations unable to respond to security
privacy issues stemming from the mandated algorithms -- IPv6 IIDs and privacy issues stemming from the mandated or recommended
need not expose privacy-sensitive link-layer addresses, and algorithms -- IPv6 IIDs need not expose privacy-sensitive link-layer
predictable Fragment Identifiers invite the same off-path attacks addresses, and predictable IPv6 Fragment Header Identification values
that plague TCP. invite the same off-path attacks that plague TCP.
Finally, there are protocol implementations that simply fail to Finally, there are protocol implementations that simply fail to
comply with existing protocol specifications. That is, appropriate comply with existing protocol specifications. That is, appropriate
guidance is provided by the protocol specification (whether the core guidance is provided by the protocol specification (whether it be the
specification or an update to it), but an implementation simply fails core specification or an update to it), but an implementation simply
to follow such guidance. For example, some popular operating systems fails to follow such guidance. For example, some popular operating
still fail to implement transport-protocol port randomization, as systems still fail to implement transport-protocol port
specified in [RFC6056]. randomization, as specified in [RFC6056].
Clear specification of the interoperability requirements for the Clear specification of the interoperability requirements for the
transient numeric identifiers will help identify possible algorithms transient numeric identifiers will help identify possible algorithms
that could be employed to generate them, and also make evident if that could be employed to generate them and also make evident if such
such identifiers are being over-specified. A protocol specification identifiers are being over specified. A protocol specification will
will usually also benefit from a vulnerability assessment of the usually also benefit from a vulnerability assessment of the transient
transient numeric identifiers they specify, to prevent the numeric identifiers they specify to prevent the corresponding
corresponding considerations from being overlooked. considerations from being overlooked.
4. Common Flaws in the Generation of Transient Numeric Identifiers 4. Common Flaws in the Generation of Transient Numeric Identifiers
This section briefly notes common flaws associated with the This section briefly notes common flaws associated with the
generation of transient numeric identifiers. Such common flaws generation of transient numeric identifiers. Such common flaws
include, but are not limited to: include, but are not limited to:
* Employing trivial algorithms (e.g. global counters) that result in * employing trivial algorithms (e.g., global counters) that result
predictable identifiers in predictable identifiers,
* Employing the same identifier across contexts in which constancy * employing the same identifier across contexts in which constancy
is not required is not required,
* Re-using identifiers across different protocols or layers of the * reusing identifiers across different protocols or layers of the
protocol stack protocol stack,
* Initializing counters or timers to constant values, when such * initializing counters or timers to constant values when such
initialization is not required initialization is not required,
* Employing the same increment space across different contexts * employing the same increment space across different contexts, and
* Use of flawed pseudo-random number generators (PRNGs). * use of flawed Pseudorandom Number Generators (PRNGs).
Employing trivial algorithms for generating the identifiers means Employing trivial algorithms for generating the identifiers means
that any node that is able to sample such identifiers can easily that any node that is able to sample such identifiers can easily
predict future identifiers employed by the victim node. predict future identifiers employed by the victim node.
When one identifier is employed across contexts where such constancy When one identifier is employed across contexts where such constancy
is not needed, activity correlation is made possible. For example, is not needed, activity correlation is made possible. For example,
employing an identifier that is constant across networks allows for employing an identifier that is constant across networks allows for
node tracking across networks. node tracking across networks.
Re-using identifiers across different layers or protocols ties the Reusing identifiers across different layers or protocols ties the
security and privacy properties of the protocol re-using the security and privacy properties of the protocol reusing the
identifier to the security and privacy properties of the original identifier to the security and privacy properties of the original
identifier (over which the protocol re-using the identifier may have identifier (over which the protocol reusing the identifier may have
no control regarding its generation). Besides, when re-using an no control regarding its generation). Besides, when reusing an
identifier across protocols from different layers, the goal of identifier across protocols from different layers, the goal of
isolating the properties of a layer from that of another layer is isolating the properties of a layer from those of another layer is
broken, and the vulnerability assessment may be harder to perform, broken, and the vulnerability assessment may be harder to perform
since the combined system, rather than each protocol in isolation since the combined system, rather than each protocol in isolation,
will have to be assessed. will have to be assessed.
At times, a protocol needs to convey order information (whether At times, a protocol needs to convey order information (whether it be
sequence, timing, etc.). In many cases, there is no reason for the sequence, timing, etc.). In many cases, there is no reason for the
corresponding counter or timer to be initialized to any specific corresponding counter or timer to be initialized to any specific
value e.g. at system bootstrap. Similarly, there may not be a need value, e.g., at system bootstrap. Similarly, there may not be a need
for the difference between successive counted values to be a for the difference between successive counter values to be
predictable. predictable.
A node that implements a per-context linear function may share the A node that implements a per-context linear function may share the
increment space among different contexts (please see the "Simple increment space among different contexts (please see the "Simple PRF-
Hash-Based Algorithm" in [I-D.irtf-pearg-numeric-ids-generation]). Based Algorithm" section in [RFC9415]). Sharing the same increment
Sharing the same increment space allows an attacker that can sample space allows an attacker that can sample identifiers in other context
identifiers in other context to e.g. learn how many identifiers have to, e.g., learn how many identifiers have been generated between two
been generated between two sampled values. sampled values.
Finally, some implementations have been found to employ flawed PRNGs Finally, some implementations have been found to employ flawed PRNGs
(see e.g. [Klein2007]). (e.g., see [Klein2007]).
5. Requirements for Transient Numeric Identifiers 5. Requirements for Transient Numeric Identifiers
Protocol specifications that employ transient numeric identifiers Protocol specifications that employ transient numeric identifiers
MUST explicitly specify the interoperability requirements for the MUST explicitly specify the interoperability requirements for the
aforementioned transient numeric identifiers (e.g., required aforementioned transient numeric identifiers (e.g., required
properties such as uniqueness, along with the failure severity if properties such as uniqueness, along with the failure severity if
such properties are not met). such requirements are not met).
A vulnerability assessment of the aforementioned transient numeric A vulnerability assessment of the aforementioned transient numeric
identifiers MUST be performed as part of the specification process. identifiers MUST be performed as part of the specification process.
Such vulnerability assessment should cover, at least, spoofing, Such vulnerability assessment should cover, at least, spoofing,
tampering, repudiation, information disclosure, denial of service, tampering, repudiation, information disclosure, DoS, and elevation of
and elevation of privilege. privilege.
Note: Section 8 and Section 9 of | NOTE: Sections 8 and 9 of [RFC9415] provide a general
[I-D.irtf-pearg-numeric-ids-generation] provide a general | vulnerability assessment of transient numeric identifiers,
vulnerability assessment of transient numeric identifiers, along | along with a vulnerability assessment of common algorithms for
with a vulnerability assessment of common algorithms for | generating transient numeric identifiers. Please see
generating transient numeric identifiers. Please see | [Shostack2014] for further guidance on threat modeling.
[Shostack2014] for further guidance on threat modelling.
Protocol specifications SHOULD NOT employ predictable transient Protocol specifications SHOULD NOT employ predictable transient
numeric identifiers, except when such predictability is the result of numeric identifiers, except when such predictability is the result of
their interoperability requirements. their interoperability requirements.
Protocol specifications that employ transient numeric identifiers Protocol specifications that employ transient numeric identifiers
SHOULD recommend an algorithm for generating the aforementioned SHOULD recommend an algorithm for generating the aforementioned
transient numeric identifiers that mitigates the vulnerabilities transient numeric identifiers that mitigates the vulnerabilities
identified in the previous step, such as those discussed in identified in the previous step, such as those discussed in
[I-D.irtf-pearg-numeric-ids-generation]. [RFC9415].
As discussed in Section 1, use of cryptographic techniques for As discussed in Section 1, use of cryptographic techniques for
confidentiality and authentication might not eliminate all the issues confidentiality and authentication might not eliminate all the issues
associated with predictable transient numeric identifiers. associated with predictable transient numeric identifiers.
Therefore, the advice from this section MUST still be applied for Therefore, the advice from this section MUST still be applied for
cases where cryptographic techniques are employed for confidentiality cases where cryptographic techniques for confidentiality or
or authentication of the associated transient numeric identifiers. authentication are employed.
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 entire document is about the security and privacy implications This entire document is about the security and privacy implications
of transient numeric identifiers, and formally updates [RFC3552] such of transient numeric identifiers and formally updates [RFC3552] such
that the security and privacy implications of transient numeric that the security and privacy implications of transient numeric
identifiers are addressed when writing the "Security Considerations" identifiers are addressed when writing the "Security Considerations"
section of future RFCs. section of future RFCs.
8. Acknowledgements 8. References
The authors would like to thank Bernard Aboba, Brian Carpenter, Roman
Danyliw, Theo de Raadt, Lars Eggert, Russ Housley, Benjamin Kaduk,
Charlie Kaufman, Erik Kline, Alvaro Retana, Joe Touch, Michael
Tuexen, Robert Wilton, and Paul Wouters, for providing valuable
comments on earlier versions of this document.
The authors would like to thank (in alphabetical order) Steven
Bellovin, Joseph Lorenzo Hall, Gre Norcie, for providing valuable
comments on [I-D.gont-predictable-numeric-ids] , on which the present
document is based.
The authors would like to thank Diego Armando Maradona for his magic
and inspiration.
9. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
9.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[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>.
[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>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
<https://www.rfc-editor.org/info/rfc6274>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", Post to Bugtraq
mailing-list, Mon Dec 14 1998,
<https://seclists.org/bugtraq/1998/Dec/48>.
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 8.2. Informative References
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>.
[Bellovin1989] [Bellovin1989]
Bellovin, S., "Security Problems in the TCP/IP Protocol Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review, vol. 19, no. 2, Suite", Computer Communications Review, vol. 19, no. 2,
pp. 32-48, 1989, pp. 32-48, April 1989,
<https://www.cs.columbia.edu/~smb/papers/ipext.pdf>. <https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.
[IANA-PROT]
IANA, "Protocol Registries",
<https://www.iana.org/protocols>.
[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", October 2007,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>.
[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>.
[PREDICTABLE-NUMERIC-IDS]
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>.
[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,
DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[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>.
[Silbersack2005] [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Silbersack, M.J., "Improving TCP/IP security through Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
randomization without sacrificing interoperability", <https://www.rfc-editor.org/info/rfc6274>.
EuroBSDCon 2005 Conference, 2005,
<http://www.silby.com/eurobsdcon05/
eurobsdcon_silbersack.pdff>.
[I-D.gont-predictable-numeric-ids] [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Gont, F. and I. Arce, "Security and Privacy Implications Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
of Numeric Identifiers Employed in Network Protocols", 2012, <https://www.rfc-editor.org/info/rfc6528>.
Work in Progress, Internet-Draft, draft-gont-predictable-
numeric-ids-03, 11 March 2019, [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
<https://www.ietf.org/archive/id/draft-gont-predictable- Interface Identifiers with IPv6 Stateless Address
numeric-ids-03.txt>. Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, Scheffenegger, Ed., "TCP Extensions for High Performance",
November 1987, <https://www.rfc-editor.org/info/rfc1035>. RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
2006, <https://www.rfc-editor.org/info/rfc4291>. <https://www.rfc-editor.org/info/rfc7707>.
[Klein2007] [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Considerations for IPv6 Address Generation Mechanisms",
Predictable IP ID Vulnerability", 2007, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_ <https://www.rfc-editor.org/info/rfc7721>.
DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>. [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[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>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9414] Gont, F. and I. Arce, "Unfortunate History of Transient
Numeric Identifiers", RFC 9414, DOI 10.17487/RFC9414, July
2023, <https://www.rfc-editor.org/info/rfc9414>.
[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/rfc941v>.
[Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", message to the
Bugtraq mailing list, December 1998,
<https://seclists.org/bugtraq/1998/Dec/48>.
[Schuba1993] [Schuba1993]
Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME Schuba, C., "Addressing Weakness in the Domain Name System
SYSTEM PROTOCOL", 1993, Protocol", August 1993,
<http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/ <http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/
schuba-DNS-msthesis.pdf>. schuba-DNS-msthesis.pdf>.
[Shostack2014] [Shostack2014]
Shostack, A., "Threat Modeling: Designing for Security", Shostack, A., "Threat Modeling: Designing for Security",
Wiley, 1st edition, 2014. Wiley, 1st edition, February 2014.
[I-D.irtf-pearg-numeric-ids-history] [Silbersack2005]
Gont, F. and I. Arce, "Unfortunate History of Transient Silbersack, M., "Improving TCP/IP security through
Numeric Identifiers", Work in Progress, Internet-Draft, randomization without sacrificing interoperability",
draft-irtf-pearg-numeric-ids-history-11, 11 December 2022, EuroBSDCon 2005 Conference, January 2005,
<https://www.ietf.org/archive/id/draft-irtf-pearg-numeric- <http://www.silby.com/eurobsdcon05/
ids-history-11.txt>. eurobsdcon_silbersack.pdf>.
[I-D.irtf-pearg-numeric-ids-generation] [TCPT-uptime]
Gont, F. and I. Arce, "On the Generation of Transient McDanel, B., "TCP Timestamping - Obtaining System Uptime
Numeric Identifiers", Work in Progress, Internet-Draft, Remotely", message to the Bugtraq mailing list, March
draft-irtf-pearg-numeric-ids-generation-12, 11 December 2001, <https://seclists.org/bugtraq/2001/Mar/182>.
2022, <https://www.ietf.org/archive/id/draft-irtf-pearg-
numeric-ids-generation-12.txt>.
[IANA-PROT] Acknowledgements
IANA, "Protocol Registries",
<https://www.iana.org/protocols>. The authors would like to thank (in alphabetical order) Bernard
Aboba, Brian Carpenter, Roman Danyliw, Theo de Raadt, Lars Eggert,
Russ Housley, Benjamin Kaduk, Charlie Kaufman, Erik Kline, Alvaro
Retana, Joe Touch, Michael Tüxen, Robert Wilton, and Paul Wouters for
providing valuable comments on draft versions of this document.
The authors would like to thank (in alphabetical order) Steven
Bellovin, Joseph Lorenzo Hall, and Gre Norcie for providing valuable
comments on [PREDICTABLE-NUMERIC-IDS], on which the present document
is based.
The authors would like to thank Diego Armando Maradona for his magic
and inspiration.
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. 75 change blocks. 
286 lines changed or deleted 309 lines changed or added

This html diff was produced by rfcdiff 1.48.