draft-ietf-6man-stable-privacy-addresses-09.txt   draft-ietf-6man-stable-privacy-addresses-10.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Intended status: Standards Track June 3, 2013 Intended status: Standards Track June 12, 2013
Expires: December 5, 2013 Expires: December 14, 2013
A method for Generating Stable Privacy-Enhanced Addresses with IPv6 A method for Generating Stable Privacy-Enhanced Addresses with IPv6
Stateless Address Autoconfiguration (SLAAC) Stateless Address Autoconfiguration (SLAAC)
draft-ietf-6man-stable-privacy-addresses-09 draft-ietf-6man-stable-privacy-addresses-10
Abstract Abstract
This document specifies a method for generating IPv6 Interface This document specifies a method for generating IPv6 Interface
Identifiers to be used with IPv6 Stateless Address Autoconfiguration Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), such that addresses configured using this method are stable (SLAAC), such that addresses configured using this method are stable
within each subnet, but the Interface Identifier changes when hosts within each subnet, but the Interface Identifier changes when hosts
move from one network to another. This method is meant to be an move from one network to another. This method is meant to be an
alternative to generating Interface Identifiers based on hardware alternative to generating Interface Identifiers based on hardware
address (e.g., using IEEE identifiers), such that the benefits of address (e.g., using IEEE identifiers), such that the benefits of
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 5, 2013. This Internet-Draft will expire on December 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 33 skipping to change at page 2, line 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Possible sources for the Net_Iface parameter . . . . 22 Appendix A. Possible sources for the Net_Iface parameter . . . . 22
A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 22 A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 22
A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . . 22 A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . . 22
A.3. Link-layer Addresses . . . . . . . . . . . . . . . . . . . 22 A.3. Link-layer Addresses . . . . . . . . . . . . . . . . . . . 22
A.4. Logical Network Service Identity . . . . . . . . . . . . . 23 A.4. Logical Network Service Identity . . . . . . . . . . . . . 23
Appendix B. Security/privacy issues with traditional SLAAC Appendix B. Security/privacy issues with traditional SLAAC
addresses . . . . . . . . . . . . . . . . . . . . . . 24 addresses . . . . . . . . . . . . . . . . . . . . . . 24
B.1. Correlation of node activities within the same network . . 24 B.1. Correlation of node activities within the same network . . 24
B.2. Correlation of node activities across networks . . . . . . 24 B.2. Correlation of node activities across networks (host
B.3. Host-tracking attacks . . . . . . . . . . . . . . . . . . 24 tracking) . . . . . . . . . . . . . . . . . . . . . . . . 24
B.4. Address-scanning attacks . . . . . . . . . . . . . . . . . 25 B.3. Address-scanning attacks . . . . . . . . . . . . . . . . . 25
B.5. Exploitation of device-specific information . . . . . . . 25 B.4. Exploitation of device-specific information . . . . . . . 25
Appendix C. Privacy issues still present when temporary Appendix C. Privacy issues still present when temporary
addresses are employed . . . . . . . . . . . . . . . 26 addresses are employed . . . . . . . . . . . . . . . 26
C.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 26 C.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 26
C.1.1. Tracking hosts across networks #1 . . . . . . . . . . 26 C.1.1. Tracking hosts across networks #1 . . . . . . . . . . 26
C.1.2. Tracking hosts across networks #2 . . . . . . . . . . 27 C.1.2. Tracking hosts across networks #2 . . . . . . . . . . 27
C.1.3. Revealing the identity of devices performing C.1.3. Revealing the identity of devices performing
server-like functions . . . . . . . . . . . . . . . . 27 server-like functions . . . . . . . . . . . . . . . . 27
C.2. Address-scanning attacks . . . . . . . . . . . . . . . . . 27 C.2. Address-scanning attacks . . . . . . . . . . . . . . . . . 27
C.3. Information Leakage . . . . . . . . . . . . . . . . . . . 28 C.3. Information Leakage . . . . . . . . . . . . . . . . . . . 28
C.4. Correlation of node activities within a network . . . . . 28 C.4. Correlation of node activities within a network . . . . . 28
skipping to change at page 5, line 33 skipping to change at page 5, line 33
moves from one network to another. moves from one network to another.
The method specified in this document is a orthogonal to the use of The method specified in this document is a orthogonal to the use of
"temporary" addresses [RFC4941], since it is meant to improve the "temporary" addresses [RFC4941], since it is meant to improve the
security and privacy properties of the stable addresses that are security and privacy properties of the stable addresses that are
employed along with the aforementioned "temporary" addresses. In employed along with the aforementioned "temporary" addresses. In
scenarios in which "temporary addresses" are employed, implementation scenarios in which "temporary addresses" are employed, implementation
of the mechanism described in this document (in replacement of stable of the mechanism described in this document (in replacement of stable
addresses based on e.g. IEEE identifiers) would mitigate address- addresses based on e.g. IEEE identifiers) would mitigate address-
scanning attacks and also mitigate the remaining vectors for scanning attacks and also mitigate the remaining vectors for
correlating host activities based on the node's IPv6 addresses. On correlating host activities based on the node's constant (i.e. stable
the other hand, for nodes that currently disable "temporary across networks) Interface Identifiers. On the other hand, for nodes
addresses" [RFC4941] for some of the reasons described earlier in that currently disable "temporary addresses" [RFC4941] for some of
this document, implementation of this mechanism will result in stable the reasons described earlier in this document, implementation of
privacy-enhanced addresses which address some of the concerns related this mechanism will result in stable privacy-enhanced addresses which
to addresses that embed IEEE identifiers [RFC4291], and which address some of the concerns related to addresses that embed IEEE
mitigate IPv6 address-scanning attacks. identifiers [RFC4291], and which mitigate IPv6 address-scanning
attacks.
We note that this method is incrementally deployable, since it does We note that this method is incrementally deployable, since it does
not pose any interoperability implications when deployed on networks not pose any interoperability implications when deployed on networks
where other nodes do not implement or employ it. Additionally, we where other nodes do not implement or employ it. Additionally, we
note that this document does not update or modify IPv6 StateLess note that this document does not update or modify IPv6 StateLess
Address Auto-Configuration (SLAAC) [RFC4862] itself, but rather only Address Auto-Configuration (SLAAC) [RFC4862] itself, but rather only
specifies an alternative algorithm to generate Interface Identifiers. specifies an alternative algorithm to generate Interface Identifiers.
Therefore, the usual address lifetime properties (as specified in the Therefore, the usual address lifetime properties (as specified in the
corresponding Prefix Information Options) apply when IPv6 addresses corresponding Prefix Information Options) apply when IPv6 addresses
are generated as a result of employing the algorithm specified in are generated as a result of employing the algorithm specified in
skipping to change at page 24, line 28 skipping to change at page 24, line 28
network. One sample scenario is that in which a client repeatedly network. One sample scenario is that in which a client repeatedly
connects to a server over a period of time, and hence, based on the connects to a server over a period of time, and hence, based on the
stable Interface Identifier, the server can correlate all stable Interface Identifier, the server can correlate all
communication instances as being initiated by the same node. communication instances as being initiated by the same node.
The method specified in this document does not mitigate this attack The method specified in this document does not mitigate this attack
vector, since it produces Interface Identifiers that are constant vector, since it produces Interface Identifiers that are constant
within a given network. within a given network.
This attack vector could only be mitigated by employing "temporary This attack vector could only be mitigated by employing "temporary
addresses" [RFC4941]. However, as noted earlier in this document, addresses" [RFC4941]. However, as noted in Appendix C.4, in
in scenarios in which there is a reduced number of nodes in a scenarios in which there is a reduced number of nodes in a given
given network, mitigation of this vector might be difficult (if at network, mitigation of this vector might be difficult (if at all
all possible) -- even with "temporary addresses" [RFC4941] in possible) -- even with "temporary addresses" [RFC4941] in place.
place.
B.2. Correlation of node activities across networks
Since traditional SLAAC addresses employ Interface Identifiers that
are constant across networks, such identifiers can be leveraged to
correlate the activities of a node across networks. One sample
scenario is that in which a client repeatedly connects to a server
over a period of time, and hence, based on the stable Interface
Identifier, the server can correlate all communication instances as
being initiated by the same node. Since the method specified in this
document results in Interface Identifiers that are not constant
across networks, this attack vector is mitigated.
B.3. Host-tracking attacks B.2. Correlation of node activities across networks (host tracking)
Since traditional SLAAC addresses employ Interface Identifiers that Since traditional SLAAC addresses employ Interface Identifiers that
are constant across networks, such identifiers can be leveraged to are constant across networks, such identifiers can be leveraged to
track a node across networks. correlate the activities of a node across networks.
For example, let us assume that the attacker knows the Interface A passive version of this attack would be that in which a client
Identifier employed by the target node. If the target node contacts repeatedly connects to an attacker-operated server over a period of
an attacker-operated node each time it moves from one network to time, and hence, based on the client's stable Interface Identifier,
another, the attacker will be able to track the node as it moves from the server can correlate all communication instances as being
one network to another. initiated by the same node.
An active version of this attack would imply that, once the Interface An attacker could also launch an active version of this attack. For
Identifier is known to the attacker the attacker probes whether there example, let us assume that the attacker knows the Interface
is an address with that Interface Identifier in each target network Identifier employed by the target node (e.g., the target and the
(i.e., in each network the client might connect to). If such address attacker were simultaneously connected to the same subnetwork at some
is found to be "alive", then the attacker could infer that the target point in time). If the attacker knows the possible networks the
node has connected to the corresponding network. target might connect to, he could probe whether there is an address
with the target's Interface Identifier in each of those networks. If
such address is found to be "alive", then the attacker could infer
that the target node has connected to the corresponding network.
This vector is discussed in detail in Appendix C.1.2. This vector is discussed in detail in Appendix C.1.2.
Since the method specified in this document results in Interface Since the method specified in this document results in Interface
Identifiers that are not constant across networks, this attack vector Identifiers that are not constant across networks, both the passive
is mitigated. and active versions of this attack vector are mitigated.
B.4. Address-scanning attacks B.3. Address-scanning attacks
Since traditional SLAAC addresses typically embed the underlying Since traditional SLAAC addresses typically embed the underlying
link-layer address, the aforementioned addresses follow specific link-layer address, the aforementioned addresses follow specific
patterns that can be leveraged to reduce the search space when patterns that can be leveraged to reduce the search space when
performing IPv6 address-scanning attacks (this is discussed in detail performing IPv6 address-scanning attacks (this is discussed in detail
in [I-D.ietf-opsec-ipv6-host-scanning]). The method specified in in [I-D.ietf-opsec-ipv6-host-scanning]). The method specified in
this document produces random (but table within each subnet) this document produces random (but table within each subnet)
Interface Identifiers, thus mitigating this attack vector. Interface Identifiers, thus mitigating this attack vector.
B.5. Exploitation of device-specific information B.4. Exploitation of device-specific information
Since traditional SLAAC addresses typically embed the underlying Since traditional SLAAC addresses typically embed the underlying
link-layer address, the aforementioned addresses leaks device- link-layer address, the aforementioned addresses leaks device-
specific information that might be leveraged to launch device- specific information that might be leveraged to launch device-
specific attacks. For example, an attacker with knowledge about a specific attacks. For example, an attacker with knowledge about a
specific vulnerability in devices manufactured by some vendor might specific vulnerability in devices manufactured by some vendor might
easily identify potential targets by looking at the Interface easily identify potential targets by looking at the Interface
Identifier of a list of IPv6 addresses. The method specified in this Identifier of a list of IPv6 addresses. The method specified in this
document produces random (but table within each subnet) Interface document produces random (but table within each subnet) Interface
Identifiers, thus mitigating this attack vector. Identifiers, thus mitigating this attack vector.
 End of changes. 13 change blocks. 
49 lines changed or deleted 40 lines changed or added

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