< draft-gont-numeric-ids-generation-03.txt   draft-gont-numeric-ids-generation-04.txt >
Network Working Group F. Gont Network Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks
Intended status: Best Current Practice I. Arce Intended status: Best Current Practice I. Arce
Expires: September 12, 2019 Quarkslab Expires: January 9, 2020 Quarkslab
March 11, 2019 July 8, 2019
On the Generation of Transient Numeric Identifiers On the Generation of Transient Numeric Identifiers
draft-gont-numeric-ids-generation-03 draft-gont-numeric-ids-generation-04
Abstract Abstract
This document performs an analysis of the security and privacy This document performs an analysis of the security and privacy
implications of different types of "numeric identifiers" used in IETF implications of different types of "numeric identifiers" used in IETF
protocols, and tries to categorize them based on their protocols, and tries to categorize them based on their
interoperability requirements and the associated failure severity interoperability requirements and the associated failure severity
when such requirements are not met. Subsequently, it provides advice when such requirements are not met. Subsequently, it provides advice
on possible algorithms that could be employed to satisfy the on possible algorithms that could be employed to satisfy the
interoperability requirements of each identifier type, while interoperability requirements of each identifier type, while
minimizing the security and privacy implications, thus providing minimizing the security and privacy implications, thus providing
guidance to protocol designers and protocol implementers. Finally, guidance to protocol designers and protocol implementers. Finally,
describes a number of algorithms that have been employed in real this describes a number of algorithms that have been employed in real
implementations to generate transient numeric identifiers and implementations to generate transient numeric identifiers and
analyzes their security and privacy properties. analyzes their security and privacy properties.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
9. Vulnerability Analysis of Specific Transient Numeric 9. Vulnerability Analysis of Specific Transient Numeric
Identifiers Categories . . . . . . . . . . . . . . . . . . . 19 Identifiers Categories . . . . . . . . . . . . . . . . . . . 19
9.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 19 9.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 19
9.2. Category #2: Uniqueness (hard failure) . . . . . . . . . 20 9.2. Category #2: Uniqueness (hard failure) . . . . . . . . . 20
9.3. Category #3: Uniqueness, constant within context (soft 9.3. Category #3: Uniqueness, constant within context (soft
failure) . . . . . . . . . . . . . . . . . . . . . . . . 20 failure) . . . . . . . . . . . . . . . . . . . . . . . . 20
9.4. Category #4: Uniqueness, monotonically increasing within 9.4. Category #4: Uniqueness, monotonically increasing within
context (hard failure) . . . . . . . . . . . . . . . . . 20 context (hard failure) . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Flawed Algorithms . . . . . . . . . . . . . . . . . 27 Appendix A. Flawed Algorithms . . . . . . . . . . . . . . . . . 27
A.1. Predictable Linear Identifiers Algorithm . . . . . . . . 27 A.1. Predictable Linear Identifiers Algorithm . . . . . . . . 27
A.2. Random-Increments Algorithm . . . . . . . . . . . . . . . 28 A.2. Random-Increments Algorithm . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Network protocols employ a variety of numeric identifiers for Network protocols employ a variety of numeric identifiers for
different protocol entities, ranging from DNS Transaction IDs (TxIDs) different protocol entities, ranging from DNS Transaction IDs (TxIDs)
to transport protocol numbers (e.g. TCP ports) or IPv6 Interface to transport protocol ports (e.g. TCP ports) or IPv6 Interface
Identifiers (IIDs). These identifiers usually have specific Identifiers (IIDs). These identifiers usually have specific
properties that must be satisfied such that they do not result in properties that must be satisfied such that they do not result in
negative interoperability implications (e.g. uniqueness during a negative interoperability implications (e.g. uniqueness during a
specified period of time), and associated failure severities when specified period of time), and an associated failure severity when
such properties are not met, ranging from soft to hard failures. such properties are not met, ranging from soft to hard failures.
For more than 30 years, a large number of implementations of the TCP/ For more than 30 years, a large number of implementations of the TCP/
IP protocol suite have been subject to a variety of attacks, with IP protocol suite have been subject to a variety of attacks, with
effects ranging from Denial of Service (DoS) or data injection, to effects ranging from Denial of Service (DoS) or data injection, to
information leakage that could be exploited for pervasive monitoring information leakage that could be exploited for pervasive monitoring
[RFC7528]. The root of these issues has been, in many cases, the [RFC7258]. The root of these issues has been, in many cases, the
poor selection of identifiers in such protocols, usually as a result poor selection of identifiers in such protocols, usually as a result
of an insufficient or misleading specification. While it is of insufficient or misleading specifications. While it is generally
generally trivial to identify an algorithm that can satisfy the trivial to identify an algorithm that can satisfy the
interoperability requirements for a given identifier, there exists interoperability requirements of a given identifier, there exists
practical evidence that doing so without negatively affecting the practical evidence that doing so without negatively affecting the
security and/or privacy properties of the aforementioned protocols is security and/or privacy properties of the aforementioned protocols is
prone to error. prone to error [I-D.gont-numeric-ids-history].
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:
o Predictable TCP sequence numbers o Predictable TCP sequence numbers
o Predictable transport protocol numbers o Predictable transport protocol port numbers
o Predictable IPv4 or IPv6 Fragment Identifiers o Predictable IPv4 or IPv6 Fragment Identifiers
o Predictable IPv6 IIDs o Predictable IPv6 Interface Identifiers (IIDs)
o Predictable DNS TxIDs o Predictable DNS Transaction Identifiers (TxIDs)
Recent history indicates that when new protocols are standardized or 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 identifiers tend to be overlooked and
inappropriate algorithms to generate identifier values are either inappropriate algorithms to generate transient numeric identifiers
suggested in the specification or selected by implementers. As a are either suggested in the specification or selected by
result, we believe that advice in this area is warranted. implementers. As a result, we believe that advice in this area is
warranted.
This document contains a non-exhaustive survey of identifiers This document contains a non-exhaustive survey of identifiers
employed in various IETF protocols, and aims to categorize such employed in various IETF protocols, and aims to categorize such
identifiers based on their interoperability requirements, and the identifiers based on their interoperability requirements, and the
associated failure severity when such requirements are not met. associated failure severity when such requirements are not met.
Subsequently, it provides advice on possible algorithms that could be Subsequently, it provides advice on possible algorithms that could be
employed to satisfy the interoperability requirements of each employed to satisfy the interoperability requirements of each
category, while minimizing the associated security and privacy category, while minimizing the associated security and privacy
implications. Finally, it analyzes several algorithms that have been implications. Finally, it analyzes several algorithms that have been
employed in real implementations to meet such requirements and employed in real implementations to meet such requirements and
skipping to change at page 5, line 14 skipping to change at page 5, line 15
simple packet-loss event that is subsequently recovered with a simple packet-loss event that is subsequently recovered with a
retransmission can be considered a soft failure. retransmission can be considered a soft failure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Threat Model 3. Threat Model
Throughout this document, we assume an attacker does not have Throughout this document, we assume an attacker does not have
physical or logical device to the device(s) being attacked. We physical or logical access to the device(s) being attacked. We
assume the attacker can simply send any traffic to the target assume the attacker can simply send any traffic to the target
devices, to e.g. sample identifiers employed by such devices. devices, to e.g. sample identifiers employed by such devices.
4. Issues with the Specification of Identifiers 4. Issues with the Specification of Identifiers
While assessing protocol specifications regarding the use of While assessing protocol specifications regarding the use of
identifiers, we found that most of the issues discussed in this identifiers, we found that most of the issues discussed in this
document arise as a result of one of the following: document arise as a result of one of the following conditions:
o Protocol specifications which under-specify the requirements for o Protocol specifications which under-specify the requirements for
their identifiers their identifiers
o Protocol specifications that over-specify their identifiers o Protocol specifications that over-specify their identifiers
o Protocol implementations that simply fail to comply with the o Protocol implementations that simply fail to comply with the
specified requirements specified requirements
A number of protocol implementations (too many of them) simply A number of protocol implementations (too many of them) simply
overlook the security and privacy implications of identifiers. overlook the security and privacy implications of identifiers
Examples of them are the specification of TCP port numbers in [I-D.gont-numeric-ids-history]. Examples of them are the
[RFC0793], the specification of TCP sequence numbers in [RFC0793], or specification of TCP port numbers in [RFC0793], the specification of
the specification of the DNS TxID in [RFC1035]. TCP sequence numbers in [RFC0793], or the specification of the DNS
TxID in [RFC1035].
On the other hand, there are a number of protocol specifications that On the other hand, there are a number of protocol specifications that
over-specify some of their associated protocol identifiers. For over-specify some of their associated protocol identifiers. For
example, [RFC4291] essentially results in link-layer addresses being example, [RFC4291] essentially results in link-layer addresses being
embedded in the IPv6 Interface Identifiers (IIDs) when the embedded in the IPv6 Interface Identifiers (IIDs) when the
interoperability requirement of uniqueness could be achieved in other interoperability requirement of uniqueness could be achieved in other
ways that do not result in negative security and privacy implications ways that do not result in negative security and privacy implications
[RFC7721]. Similarly, [RFC2460] suggests the use of a global counter [RFC7721]. Similarly, [RFC2460] suggested the use of a global
for the generation of Fragment Identification values, when the counter for the generation of Fragment Identification values, when
interoperability properties of uniqueness per {Src IP, Dst IP} could the interoperability properties of uniqueness per {Src IP, Dst IP}
be achieved with other algorithms that do not result in negative could be achieved with other algorithms that do not result in
security and privacy implications. negative security and privacy implications.
Finally, there are protocol implementations that simply fail to Finally, there are protocol implementations that simply fail to
comply with existing protocol specifications. For example, some comply with existing protocol specifications. For example, some
popular operating systems (notably Microsoft Windows) still fail to popular operating systems (notably Microsoft Windows) still fail to
implement randomization of transport protocol ephemeral ports, as implement transport port randomization, as specified in [RFC6056].
specified in [RFC6056].
5. Protocol Failure Severity 5. Protocol Failure Severity
Section 2 defines the concept of "Failure Severity" and two types of Section 2 defines the concept of "Failure Severity" and two types of
failures that we employ throughout this document: soft and hard. failures that we employ throughout this document: soft and hard.
Our analysis of the severity of a failure is performed from the point Our analysis of the severity of a failure is performed from the point
of view of the protocol in question. However, the corresponding of view of the protocol in question. However, the corresponding
severity on the upper application or protocol may not be the same as severity on the upper application or protocol may not be the same as
that of the protocol in question. For example, a TCP connection that that of the protocol in question. For example, a TCP connection that
skipping to change at page 7, line 14 skipping to change at page 7, line 14
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| Identifier | Interoperability Requirements | Failure | | Identifier | Interoperability Requirements | Failure |
| | | Severity | | | | Severity |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| IPv6 Frag | Uniqueness (for IP address pair) | Soft/Hard (1) | | IPv6 Frag | Uniqueness (for IP address pair) | Soft/Hard (1) |
| ID | | | | ID | | |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| IPv6 IID | Uniqueness (and constant within IPv6 | Soft (3) | | IPv6 IID | Uniqueness (and constant within IPv6 | Soft (3) |
| | prefix) (2) | | | | prefix) (2) | |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| TCP SEQ | Monotonically-increasing | Hard (4) | | TCP ISN | Monotonically-increasing | Hard (4) |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| TCP eph. | Uniqueness (for connection ID) | Hard | | TCP eph. | Uniqueness (for connection ID) | Hard |
| port | | | | port | | |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| IPv6 Flow | Uniqueness | None (5) | | IPv6 Flow | Uniqueness | None (5) |
| L. | | | | L. | | |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| DNS TxID | Uniqueness | None (6) | | DNS TxID | Uniqueness | None (6) |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
skipping to change at page 7, line 40 skipping to change at page 7, line 40
While a single collision of Fragment ID values would simply lead While a single collision of Fragment ID values would simply lead
to a single packet drop (and hence a "soft" failure), repeated to a single packet drop (and hence a "soft" failure), repeated
collisions at high data rates might trash the Fragment ID space, collisions at high data rates might trash the Fragment ID space,
leading to a hard failure [RFC4963]. leading to a hard failure [RFC4963].
(2) (2)
While the interoperability requirements are simply that the While the interoperability requirements are simply that the
Interface ID results in a unique IPv6 address, for operational Interface ID results in a unique IPv6 address, for operational
reasons it is typically desirable that the resulting IPv6 address reasons it is typically desirable that the resulting IPv6 address
(and hence the corresponding Interface ID) be constant within each (and hence the corresponding Interface ID) be constant within each
network [I-D.ietf-6man-default-iids] [RFC7217]. network [RFC7217] [RFC8064] .
(3) (3)
While IPv6 Interface IDs must result in unique IPv6 addresses, While IPv6 Interface IDs must result in unique IPv6 addresses,
IPv6 Duplicate Address Detection (DAD) [RFC4862] allows for the IPv6 Duplicate Address Detection (DAD) [RFC4862] allows for the
detection of duplicate Interface IDs/addresses, and hence such detection of duplicate Interface IDs/addresses, and hence such
Interface ID collisions can be recovered. Interface ID collisions can be recovered.
(4) (4)
In theory there are no interoperability requirements for TCP In theory there are no interoperability requirements for TCP
sequence numbers, since the TIME-WAIT state and TCP's "quiet time" Initial Sequence Numbers (ISNs), since the TIME-WAIT state and
take care of old segments from previous incarnations of the TCP's "quiet time" take care of old segments from previous
connection. However, a widespread optimization allows for a new incarnations of the connection. However, a widespread
incarnation of a previous connection to be created if the Initial optimization allows for a new incarnation of a previous connection
Sequence Number (ISN) of the incoming SYN is larger than the last to be created if the ISN of the incoming SYN is larger than the
sequence number seen in that direction for the previous last sequence number seen in that direction for the previous
incarnation of the connection. Thus, monotonically-increasing TCP incarnation of the connection. Thus, monotonically-increasing TCP
sequence numbers allow for such optimization to work as expected sequence numbers allow for such optimization to work as expected
[RFC6528]. [RFC6528].
(5) (5)
The IPv6 Flow Label is typically employed for load sharing The IPv6 Flow Label is typically employed for load sharing
[RFC7098], along with the Source and Destination IPv6 addresses. [RFC7098], along with the Source and Destination IPv6 addresses.
Reuse of a Flow Label value for the same set {Source Address, Reuse of a Flow Label value for the same set {Source Address,
Destination Address} would typically cause both flows to be Destination Address} would typically cause both flows to be
multiplexed into the same link. However, as long as this does not multiplexed into the same link. However, as long as this does not
skipping to change at page 12, line 8 skipping to change at page 12, line 8
concatenation of e.g. the interface index and the SLAAC concatenation of e.g. the interface index and the SLAAC
autoconfiguration prefix (please see [RFC7217] for an implementation autoconfiguration prefix (please see [RFC7217] for an implementation
of this algorithm for the generation of IPv6 IIDs). of this algorithm for the generation of IPv6 IIDs).
The secret should be chosen to be as random as possible (see The secret should be chosen to be as random as possible (see
[RFC4086] for recommendations on choosing secrets). [RFC4086] for recommendations on choosing secrets).
For obvious reasons, the transient network identifiers generated with For obvious reasons, the transient network identifiers generated with
this algorithm allow for network activity correlation within this algorithm allow for network activity correlation within
"CONTEXT". However, this is essentially a design goal of this "CONTEXT". However, this is essentially a design goal of this
category of transient network identifiers. category of transient numeric identifiers.
7.4. Category #4: Uniqueness, monotonically increasing within context 7.4. Category #4: Uniqueness, monotonically increasing within context
(hard failure) (hard failure)
7.4.1. Per-context Counter Algorithm 7.4.1. Per-context Counter Algorithm
One possible way to achieve low identifier reuse frequency while One possible way to achieve low identifier reuse frequency while
still avoiding predictable sequences would be to employ a per-context still avoiding predictable sequences would be to employ a per-context
counter, as opposed to a global counter. Such an algorithm could be counter, as opposed to a global counter. Such an algorithm could be
described as follows: described as follows:
skipping to change at page 15, line 19 skipping to change at page 15, line 19
to produce identifiers that are monotonically-increasing for each set to produce identifiers that are monotonically-increasing for each set
(Source IP Address, Destination IP Address), the CONTEXT should be (Source IP Address, Destination IP Address), the CONTEXT should be
the concatenation of these two values. the concatenation of these two values.
The secret should be chosen to be as random as possible (see The secret should be chosen to be as random as possible (see
[RFC4086] for recommendations on choosing secrets). [RFC4086] for recommendations on choosing secrets).
It should be noted that, since this algorithm uses a global counter It should be noted that, since this algorithm uses a global counter
("counter") for selecting identifiers, this algorithm produces an ("counter") for selecting identifiers, this algorithm produces an
information leakage (as described in Section 8.2). For example, if information leakage (as described in Section 8.2). For example, if
an attacker could force a client to periodically establish a new TCP this algorithm were used for TCP ephemeral port selection, and an
attacker could force a client to periodically establish a new TCP
connection to an attacker-controlled machine (or through an attacker- connection to an attacker-controlled machine (or through an attacker-
observable routing path), the attacker could subtract consecutive observable routing path), the attacker could subtract consecutive
source port values to obtain the number of outgoing TCP connections source port values to obtain the number of outgoing TCP connections
established globally by the target host within that time period (up established globally by the target host within that time period (up
to wrap-around issues and five-tuple collisions, of course). to wrap-around issues and five-tuple collisions, of course).
7.4.3. Double-Hash Algorithm 7.4.3. Double-Hash Algorithm
A trade-off between maintaining a single global 'counter' variable A trade-off between maintaining a single global 'counter' variable
and maintaining 2**N 'counter' variables (where N is the width of the and maintaining 2**N 'counter' variables (where N is the width of the
skipping to change at page 16, line 34 skipping to change at page 16, line 34
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
'table[]' could be initialized with random values, as indicated by 'table[]' could be initialized with random values, as indicated by
the initialization code in pseudo-code above. The function G() the initialization code in pseudo-code above. The function G()
should be a cryptographic hash function. It should use the same should be a cryptographic hash function. It should use the same
CONTEXT as F(), and a secret key value to compute a value between 0 CONTEXT as F(), and a secret key value to compute a value between 0
and (TABLE_LENGTH-1). Alternatively, G() could take an "offset" as and (TABLE_LENGTH-1).
input, and perform the exclusive-or (XOR) operation between all the
bytes in 'offset'.
The array 'table[]' assures that successive identifiers for a given The array 'table[]' assures that successive identifiers for a given
context will be monotonically-increasing. However, the increments context will be monotonically-increasing. However, the increments
space is separated into TABLE_LENGTH different spaces, and thus space is separated into TABLE_LENGTH different spaces, and thus
identifier reuse frequency will be (probabilistically) lower than identifier reuse frequency will be (probabilistically) lower than
that of the algorithm in Section 7.4.2. That is, the generation of that of the algorithm in Section 7.4.2. That is, the generation of
identifier for one given context will not necessarily result in identifier for one given context will not necessarily result in
increments in the identifiers for other contexts. increments in the identifiers for other contexts.
It is interesting to note that the size of 'table[]' does not limit It is interesting to note that the size of 'table[]' does not limit
skipping to change at page 17, line 26 skipping to change at page 17, line 24
increment space (that is, using a larger value for TABLE_LENGTH) and/ increment space (that is, using a larger value for TABLE_LENGTH) and/
or by randomizing the increments. or by randomizing the increments.
Otherwise, this algorithm does not suffer from the issues discussed Otherwise, this algorithm does not suffer from the issues discussed
in Section 8. in Section 8.
8. Common Vulnerabilities Associated with Transient Numeric Identifiers 8. Common Vulnerabilities Associated with Transient Numeric Identifiers
8.1. Network Activity Correlation 8.1. Network Activity Correlation
An idetifier that is preditable or stable within a given context An identifier that is predictable or stable within a given context
allows for network activity correlation within that context. allows for network activity correlation within that context.
For example, a stable IPv6 Interface Identifier allows for network For example, a stable IPv6 Interface Identifier allows for network
activity to be correlated for the context in which that address is activity to be correlated for the context in which that address is
stable [RFC7721]. A stable-per-network (as in [RFC7217] allows for stable [RFC7721]. A stable-per-network (as in [RFC7217] allows for
network activity correlation within a network, whereas a constant network activity correlation within a network, whereas a constant
IPv6 Interface Identifier allows not only network activity IPv6 Interface Identifier allows not only network activity
correlation within the same network, but also across networks ("host correlation within the same network, but also across networks ("host
tracking"). tracking").
skipping to change at page 18, line 34 skipping to change at page 18, line 32
"global", then Fragment Identification values would be generated "global", then Fragment Identification values would be generated
with a global counter (initialized to offset()), and thus each with a global counter (initialized to offset()), and thus each
generated Fragment Identification value would leak the number of generated Fragment Identification value would leak the number of
fragmented datagrams transmitted by the node since it was fragmented datagrams transmitted by the node since it was
bootstrapped. bootstrapped.
On the other hand, linear() will be predictable within CONTEXT_2. On the other hand, linear() will be predictable within CONTEXT_2.
The predictability of linear(), irrespective of the context and/or The predictability of linear(), irrespective of the context and/or
predictability of offset(), can leak out information that is of use predictability of offset(), can leak out information that is of use
to attackers. For example, a node that selects ephemeral port to attackers. For example, a node that selects ephemeral port
numbers on as in_ numbers on as in:
ehemeral_port = offset(Dest_IP) + linear() ehemeral_port = offset(Dest_IP) + linear()
that is, with a per-destination offset, but global linear() function that is, with a per-destination offset, but global linear() function
(e.g., a global counter), will leak information about the number of (e.g., a global counter), will leak information about the number of
outgoing connections that have been issued between any two issued outgoing connections that have been issued between any two issued
outgoing connections. Similarly, a node that generates Fragment outgoing connections.
Identification values as in:
Similarly, a node that generates Fragment Identification values as
in:
Frag_ID = offset(Srd_IP, Dst_IP) + linear() Frag_ID = offset(Srd_IP, Dst_IP) + linear()
will leak out information about the number of fragmented packets that will leak out information about the number of fragmented packets that
have been transmitted between any two other transmitted fragmented have been transmitted between any two other transmitted fragmented
packets. The vulnerabilities described in [Sanfilippo1998a], packets. The vulnerabilities described in [Sanfilippo1998a],
[Sanfilippo1998b], and [Sanfilippo1999] are all associated with the [Sanfilippo1998b], and [Sanfilippo1999] are all associated with the
use of a global linear() function (i.e., a global CONTEXT_2). use of a global linear() function (i.e., a global CONTEXT_2).
8.3. Exploitation of Semantics of Transient Numeric Identifiers 8.3. Exploitation of Semantics of Transient Numeric Identifiers
skipping to change at page 19, line 17 skipping to change at page 19, line 17
Identifiers that are not semantically opaque tend to be more Identifiers that are not semantically opaque tend to be more
predictable than semantically-opaque identifiers. For example, a MAC predictable than semantically-opaque identifiers. For example, a MAC
address contains an OUI (Organizationally-Unique Identifier) which address contains an OUI (Organizationally-Unique Identifier) which
identifies the vendor that manufactured the underlying network identifies the vendor that manufactured the underlying network
interface card. This fact may be leveraged by an attacker meaning to interface card. This fact may be leveraged by an attacker meaning to
"predict" MAC addresses, if he has some knowledge about the possible "predict" MAC addresses, if he has some knowledge about the possible
NIC vendor. NIC vendor.
[RFC7707] discusses a number of techniques to reduce the search space [RFC7707] discusses a number of techniques to reduce the search space
when performing IPv6 address-scanning attacks by leveraging the when performing IPv6 address-scanning attacks by leveraging the
semantics of the IIDs produced by a number of IID-generation semantics of the IIDs produced by a number by traditional IID-
techniques. generation algorithms (now replaced by [RFC8064] with [RFC7217]).
8.4. Exploitation of Collisions of Transient Numeric Identifiers 8.4. Exploitation of Collisions of Transient Numeric Identifiers
In many cases, th collision of transient network identifiers can have In many cases, th collision of transient network identifiers can have
a hard failure severity (or result in a hard failure severity if an a hard failure severity (or result in a hard failure severity if an
attacker can cause multiple collisions deterministically, one after attacker can cause multiple collisions deterministically, one after
another). For example, predictable Fragment Identification values another). For example, predictable Fragment Identification values
open the door to Denial of Service (DoS) attacks (see e.g. open the door to Denial of Service (DoS) attacks (see e.g.
[RFC5722]. Similarly, predictable TCP ISNs open the door to trivial [RFC5722]. Similarly, predictable TCP ISNs open the door to trivial
connection-reset and data injection attacks (see e.g. connection-reset and data injection attacks (see e.g.
skipping to change at page 21, line 9 skipping to change at page 21, line 9
9.4. Category #4: Uniqueness, monotonically increasing within context 9.4. Category #4: Uniqueness, monotonically increasing within context
(hard failure) (hard failure)
A simple way to generalize algorithms employed for generating A simple way to generalize algorithms employed for generating
identifiers of Category #4 would be as follows: identifiers of Category #4 would be as follows:
/* Identifier selection function */ /* Identifier selection function */
count = max_id - min_id + 1; count = max_id - min_id + 1;
do { do {
linear(CONTEXT_2)= linear(CONTEXT_2) + increment(); linear(CONTEXT_2)= linear(CONTEXT_2) + increment();
next_id= offset(CONTEXT_1) + linear(CONTEXT_1); next_id= offset(CONTEXT_1) + linear(CONTEXT_2);
if(check_suitable_id(next_id)) if(check_suitable_id(next_id))
return next_id; return next_id;
count--; count--;
} while (count > 0); } while (count > 0);
return ERROR; return ERROR;
Essentially, an identifier (next_id) is generated by adding a linear Essentially, an identifier (next_id) is generated by adding a linear
skipping to change at page 21, line 35 skipping to change at page 21, line 35
o For the most part, it is the offset() function that results in o For the most part, it is the offset() function that results in
identifiers that are unpredictable by an off-path attacker. While identifiers that are unpredictable by an off-path attacker. While
the resulting sequence will be monotonically-increasing, the use the resulting sequence will be monotonically-increasing, the use
of an offset value that is unknown to the attacker makes the of an offset value that is unknown to the attacker makes the
resulting values unknown to the attacker. resulting values unknown to the attacker.
o The most straightforward "stateless" implementation of offset o The most straightforward "stateless" implementation of offset
would be that in which offset() is the result of a would be that in which offset() is the result of a
cryptographically-secure hash-function that takes the values that cryptographically-secure hash-function that takes the values that
identify the context and a "secret" (not shown in the figure identify the context and a "secret_key" (not shown in the figure
above) as arguments. above) as arguments.
o Another possible (but stateful) approach would be to simply o Another possible (but stateful) approach would be to simply
generate a random offset and store it in memory, and then look-up generate a random "per-context" offset and store it in memory, and
the corresponding context when a new identifier is to be selected. then look-up the corresponding context when a new identifier is to
The algorithm in Section 7.4.1 is essentially an implementation of be selected. The algorithm in Section 7.4.1 is essentially an
this type. implementation of this type.
o The linear function is incremented according to increment(). In o The linear function is incremented according to increment(). In
the most trivial case increment() could always return the constant the most trivial case increment() could always return the constant
"1". But it could also possibly return small integers such the "1". But it could also possibly return small random integers such
increments are randomized. the increments are unpredictable.
Considering the generic algorithm illustrated above we can identify Considering the generic algorithm illustrated above we can identify
the following possible vulnerabilities: the following possible vulnerabilities:
o If the offset value spans more than the necessary context, o If the offset value spans more than the necessary context,
identifiers could be unnecessarily predictable by other parties, identifiers could be unnecessarily predictable by other parties,
since the offset value would be unnecessarily leaked to them. For since the offset value would be unnecessarily leaked to them. For
example, an implementation that means to produce a per-destination example, an implementation that means to produce a per-destination
counter but replaces offset() with a constant number (i.e., counter but replaces offset() with a constant number (i.e.,
employs a global counter), will unnecessarily result in employs a global counter), will unnecessarily result in
predictable identifiers. predictable identifiers.
o The function linear() could be seen as representing the number of o The function linear() could be seen as representing the number of
identifiers that have so far been generated for a given context identifiers that have so far been generated for a given context
(CONTEXT_2). If linear() spans more than the necessary context, (CONTEXT_2). If linear() spans more than the necessary context,
the "increments" could be leaked to other parties, thus disclosing the "increments" could be leaked to other parties, thus disclosing
information about the number of identifiers that have so far been information about the number of identifiers that have so far been
generated. For example, an implementation in which linear() is generated. For example, an implementation in which linear() is
implemented as a single global counter will unnecessarily leak implemented as a single global counter will unnecessarily leak
information the number of identifiers that have been produced. information the number of identifiers that have been produced.
[Fyodor2004] is one example of how such information leakages can
be exploited.
o increment() determines how the linear() is incremented for each o increment() determines how the linear() is incremented for each
identifier that is selected. In the most trivial case, identifier that is selected. In the most trivial case,
increment() will return the integer "1". However, an increment() will return the integer "1". However, an
implementation may have increment() return a "small" integer value implementation may have increment() return a "small" random
such that even if the current value employed by the generator is integer value such that even if the current value employed by the
guessed (see Appendix A of [RFC7739]), the exact next identifier generator is guessed (see Appendix A of [RFC7739]), the exact next
to be selected will be slightly harder to identify. identifier to be selected will be slightly harder to identify.
10. IANA Considerations 10. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
11. Security Considerations 11. Security Considerations
The entire document is about the security and privacy implications of The entire document is about the security and privacy implications of
identifiers. identifiers. [I-D.gont-numeric-ids-sec-considerations] formally
requires protocols specifications to include an appropriate analysis
of the interoperability, security, and privacy implications of the
transient numeric identifiers they specify, while this document
analyzes possible algorithms (and their implications) that could be
employed to comply with the interoperability properties of a
transient numeric identifier, while mitigating the possible security
and privacy implications.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank (in alphabetical order) Steven The authors would like to thank (in alphabetical order) Steven
Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
providing valuable comments on earlier versions of this document. providing valuable comments on earlier versions of this document.
The authors would like to thank Diego Armando Maradona for his magic The authors would like to thank Diego Armando Maradona for his magic
and inspiration. and inspiration.
skipping to change at page 24, line 5 skipping to change at page 24, line 11
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>. 2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
13.2. Informative References [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[Bellovin1989] 13.2. Informative References
Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review, vol. 19, no. 2,
pp. 32-48, 1989,
<https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.
[Bellovin2002] [Bellovin2002]
Bellovin, S., "A Technique for Counting NATted Hosts", Bellovin, S., "A Technique for Counting NATted Hosts",
IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
[CERT2001]
CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
TCP/IP Initial Sequence Numbers", 2001,
<http://www.cert.org/advisories/CA-2001-09.html>.
[CPNI-TCP] [CPNI-TCP]
Gont, F., "Security Assessment of the Transmission Control Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", United Kingdom's Centre for the Protocol (TCP)", United Kingdom's Centre for the
Protection of National Infrastructure (CPNI) Technical Protection of National Infrastructure (CPNI) Technical
Report, 2009, <http://www.gont.com.ar/papers/ Report, 2009, <https://www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf>. tn-03-09-security-assessment-TCP.pdf>.
[FIPS-SHS] [FIPS-SHS]
FIPS, "Secure Hash Standard (SHS)", Federal Information FIPS, "Secure Hash Standard (SHS)", Federal Information
Processing Standards Publication 180-4, March 2012, Processing Standards Publication 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[Fyodor2004] [Fyodor2004]
Fyodor, "Idle scanning and related IP ID games", 2004, Fyodor, "Idle scanning and related IP ID games", 2004,
<http://www.insecure.org/nmap/idlescan.html>. <http://www.insecure.org/nmap/idlescan.html>.
[I-D.ietf-6man-default-iids] [I-D.gont-numeric-ids-history]
Gont, F., Cooper, A., Thaler, D., and S. LIU, Gont, F. and I. Arce, "Unfortunate History of Transient
"Recommendation on Stable IPv6 Interface Identifiers", Numeric Identifiers", draft-gont-numeric-ids-history-04
draft-ietf-6man-default-iids-16 (work in progress), (work in progress), March 2019.
September 2016.
[I-D.gont-numeric-ids-sec-considerations]
Gont, F. and I. Arce, "Security Considerations for
Transient Numeric Identifiers Employed in Network
Protocols", draft-gont-numeric-ids-sec-considerations-03
(work in progress), April 2019.
[Joncheray1995] [Joncheray1995]
Joncheray, L., "A Simple Active Attack Against TCP", Proc. Joncheray, L., "A Simple Active Attack Against TCP", Proc.
Fifth Usenix UNIX Security Symposium, 1995. Fifth Usenix UNIX Security Symposium, 1995.
[Klein2007] [Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", 2007, Predictable IP ID Vulnerability", 2007,
<http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning <http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning
_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>. _and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>.
skipping to change at page 25, line 45 skipping to change at page 25, line 45
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Load Balancing in Server Farms", RFC 7098, Flow Label for Load Balancing in Server Farms", RFC 7098,
DOI 10.17487/RFC7098, January 2014, DOI 10.17487/RFC7098, January 2014,
<https://www.rfc-editor.org/info/rfc7098>. <https://www.rfc-editor.org/info/rfc7098>.
[RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN) [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
Association", RFC 7528, DOI 10.17487/RFC7528, April 2015, 2014, <https://www.rfc-editor.org/info/rfc7258>.
<https://www.rfc-editor.org/info/rfc7528>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>. <https://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
skipping to change at page 26, line 42 skipping to change at page 26, line 42
<3g5gkl$5j1@ariel.sdsc.edu>, 1995, <3g5gkl$5j1@ariel.sdsc.edu>, 1995,
<http://www.gont.com.ar/docs/post-shimomura-usenet.txt>. <http://www.gont.com.ar/docs/post-shimomura-usenet.txt>.
[Silbersack2005] [Silbersack2005]
Silbersack, M., "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, 2005,
<http://citeseerx.ist.psu.edu/viewdoc/ <http://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>.
[USCERT2001]
US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple
TCP/IP implementations may use statistically predictable
initial sequence numbers", 2001,
<http://www.kb.cert.org/vuls/id/498440>.
[Zalewski2001] [Zalewski2001]
Zalewski, M., "Strange Attractors and TCP/IP Sequence Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis", 2001, Number Analysis", 2001,
<http://lcamtuf.coredump.cx/oldtcp/tcpseq.html>. <http://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.
[Zalewski2002] [Zalewski2002]
Zalewski, M., "Strange Attractors and TCP/IP Sequence Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis - One Year Later", 2001, Number Analysis - One Year Later", 2001,
<http://lcamtuf.coredump.cx/newtcp/>. <http://lcamtuf.coredump.cx/newtcp/>.
Appendix A. Flawed Algorithms Appendix A. Flawed Algorithms
The following subsections document algorithms with known negative The following subsections document algorithms with known negative
security and privacy imlpications. security and privacy implications.
A.1. Predictable Linear Identifiers Algorithm A.1. Predictable Linear Identifiers Algorithm
One of the most trivial ways to achieve uniqueness with a low One of the most trivial ways to achieve uniqueness with a low
identifier reuse frequency is to produce a linear sequence. identifier reuse frequency is to produce a linear sequence.
For example, the following algorithm has been employed (see e.g. For example, the following algorithm has been employed (see e.g.
[Morris1985], [Shimomura1995], [Silbersack2005] and [CPNI-TCP]) in a [Morris1985], [Shimomura1995], [Silbersack2005] and [CPNI-TCP]) in a
number of operating systems for selecting IP fragment IDs, TCP number of operating systems for selecting IP fragment IDs, TCP
ephemeral ports, etc.: ephemeral ports, etc.:
skipping to change at page 30, line 10 skipping to change at page 30, line 10
o It should maximize obfuscation. o It should maximize obfuscation.
Clearly, these are competing goals, and the decision of which value Clearly, these are competing goals, and the decision of which value
of "id_inc" to use is a trade-off. Therefore, the value of "id_inc" of "id_inc" to use is a trade-off. Therefore, the value of "id_inc"
should be configurable so that system administrators can make the should be configurable so that system administrators can make the
trade-off for themselves. trade-off for themselves.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: https://www.si6networks.com
Ivan Arce Ivan Arce
Quarkslab Quarkslab
Email: iarce@quarkslab.com Email: iarce@quarkslab.com
URI: https://www.quarkslab.com URI: https://www.quarkslab.com
 End of changes. 47 change blocks. 
96 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/