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/ |