draft-ietf-6man-stable-privacy-addresses-05.txt   draft-ietf-6man-stable-privacy-addresses-06.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 March 22, 2013 Intended status: Standards Track April 12, 2013
Expires: September 23, 2013 Expires: October 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-05 draft-ietf-6man-stable-privacy-addresses-06
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. The aforementioned method is meant move from one network to another. The aforementioned method is meant
to be an alternative to generating Interface Identifiers based on to be an alternative to generating Interface Identifiers based on
IEEE identifiers, such that the benefits of stable addresses can be IEEE identifiers, such that the benefits of stable addresses can be
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 23, 2013. This Internet-Draft will expire on October 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 3, line 44 skipping to change at page 3, line 44
"privacy addresses" [RFC4941] do not eliminate the use of fixed "privacy addresses" [RFC4941] do not eliminate the use of fixed
identifiers for server-like functions, they only *partially* identifiers for server-like functions, they only *partially*
mitigate the correlation of host activities (see Appendix A for mitigate the correlation of host activities (see Appendix A for
some example attacks that are still possible with privacy some example attacks that are still possible with privacy
addresses). Therefore, it is vital that the privacy addresses). Therefore, it is vital that the privacy
characteristics of "stable" addresses are improved such that the characteristics of "stable" addresses are improved such that the
ability of an attacker correlating host activities across networks ability of an attacker correlating host activities across networks
is reduced. is reduced.
Another important aspect not mitigated by "Privacy Addresses" Another important aspect not mitigated by "Privacy Addresses"
[RFC4941] is that of host scanning. Since IPv6 addresses that [RFC4941] is that of IPv6 address scanning. Since IPv6 addresses
embed IEEE identifiers have specific patterns, an attacker could that embed IEEE identifiers have specific patterns, an attacker
leverage such patterns to greatly reduce the search space for could leverage such patterns to greatly reduce the search space
"live" hosts. Since "privacy addresses" do not eliminate the use for "live" hosts. Since "privacy addresses" do not eliminate the
of IPv6 addresses that embed IEEE identifiers, host scanning use of IPv6 addresses that embed IEEE identifiers, address
attacks are still feasible even if "privacy extensions" are scanning attacks are still feasible even if "privacy extensions"
employed [Gont-DEEPSEC2011] [CPNI-IPv6]. This is yet another are employed [Gont-DEEPSEC2011] [CPNI-IPv6]. This is yet another
motivation to improve the privacy characteristics of "stable" motivation to improve the privacy characteristics of "stable"
addresses (currently embedding IEEE identifiers). addresses (currently embedding IEEE identifiers).
Privacy/temporary addresses can be challenging in a number of areas. Privacy/temporary addresses can be challenging in a number of areas.
For example, from a network-management point of view, they tend to For example, from a network-management point of view, they tend to
increase the complexity of event logging, trouble-shooting, and increase the complexity of event logging, trouble-shooting, and
enforcing access controls and quality of service, etc. As a result, enforcing access controls and quality of service, etc. As a result,
some organizations disable the use of privacy addresses even at the some organizations disable the use of privacy addresses even at the
expense of reduced privacy [Broersma]. Also, they result in expense of reduced privacy [Broersma]. Also, they result in
increased complexity, which might not be possible or desirable in increased complexity, which might not be possible or desirable in
skipping to change at page 4, line 27 skipping to change at page 4, line 27
identifiers, and this is yet another case in which it is also vital identifiers, and this is yet another case in which it is also vital
that the privacy characteristics of these stable addresses are that the privacy characteristics of these stable addresses are
improved. improved.
We note that in most (if not all) of those scenarios in which We note that in most (if not all) of those scenarios in which
"Privacy Extensions" are disabled, there is usually no actual desire "Privacy Extensions" are disabled, there is usually no actual desire
to negatively affect user privacy, but rather a desire to simplify to negatively affect user privacy, but rather a desire to simplify
operation of the network (simplify the use of ACLs, logging, etc.). operation of the network (simplify the use of ACLs, logging, etc.).
This document specifies a method to generate interface identifiers This document specifies a method to generate interface identifiers
that are stable/constant within each subnet, but that change as hosts that are stable/constant for each network interface within each
move from one network to another, thus keeping the "stability" subnet, but that change as hosts move from one network to another,
properties of the interface identifiers specified in [RFC4291], while thus keeping the "stability" properties of the interface identifiers
still mitigating host-scanning attacks and preventing correlation of specified in [RFC4291], while still mitigating address-scanning
the activities of a node as it moves from one network to another. attacks and preventing correlation of the activities of a node as it
moves from one network to another.
We note that this method is incrementally deployable, since it does
not pose any interoperability implications when deployed on networks
where other nodes do not implement or employ it.
This document does not update or modify IPv6 StateLess Address Auto- This document does not update or modify IPv6 StateLess Address Auto-
Configuration (SLAAC) [RFC4862] itself, but rather only specifies an Configuration (SLAAC) [RFC4862] itself, but rather only specifies an
alternative algorithm to generate Interface IDs. Therefore, the alternative algorithm to generate Interface IDs. Therefore, the
usual address lifetime properties (as specified in the corresponding usual address lifetime properties (as specified in the corresponding
Prefix Information Options) apply when IPv6 addresses are generated Prefix Information Options) apply when IPv6 addresses are generated
as a result of employing the algorithm specified in this document as a result of employing the algorithm specified in this document
with SLAAC [RFC4862]. Additionally, from the point of view of with SLAAC [RFC4862]. Additionally, from the point of view of
renumbering, we note that these addresses behave like the traditional renumbering, we note that these addresses behave like the traditional
IPv6 addresses (that embed a hardware address) resulting from SLAAC IPv6 addresses (that embed a hardware address) resulting from SLAAC
skipping to change at page 6, line 40 skipping to change at page 6, line 40
other addresses. other addresses.
o The aforementioned interface identifiers are meant to be an o The aforementioned interface identifiers are meant to be an
alternative to those based on e.g. IEEE identifiers, such as alternative to those based on e.g. IEEE identifiers, such as
those specified in [RFC2464]. those specified in [RFC2464].
We note that of use of the algorithm specified in this document is We note that of use of the algorithm specified in this document is
(to a large extent) orthogonal to the use of "Privacy Extensions" (to a large extent) orthogonal to the use of "Privacy Extensions"
[RFC4941]. Hosts that do not implement/use "Privacy Extensions" [RFC4941]. Hosts that do not implement/use "Privacy Extensions"
would have the benefit that they would not be subject to the host- would have the benefit that they would not be subject to the host-
tracking and host scanning issues discussed in the previous section. tracking and address scanning issues discussed in the previous
On the other hand, in the case of hosts employing "Privacy section. On the other hand, in the case of hosts employing "Privacy
Extensions", the method specified in this document would prevent host Extensions", the method specified in this document would prevent
scanning attacks and correlation of node activities across networks address scanning attacks and correlation of node activities across
(see Appendix A). networks (see Appendix A).
3. Algorithm specification 3. Algorithm specification
IPv6 implementations conforming to this specification MUST generate IPv6 implementations conforming to this specification MUST generate
interface identifiers using the algorithm specified in this section interface identifiers using the algorithm specified in this section
in replacement of any other algorithms used for generating "stable" in replacement of any other algorithms used for generating "stable"
addresses (such as that specified in [RFC2464]). The aforementioned addresses (such as that specified in [RFC2464]). The aforementioned
algorithm MUST be employed for generating the interface identifiers algorithm MUST be employed for generating the interface identifiers
for all of the IPv6 addresses configured with SLAAC for a given for all of the IPv6 addresses configured with SLAAC for a given
interface, including IPv6 link-local addresses. interface, including IPv6 link-local addresses.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
the attacker may simply search the entire secret-key space to find the attacker may simply search the entire secret-key space to find
matches. To protect against this, the secret key should be of a matches. To protect against this, the secret key should be of a
reasonable length. Key lengths of at least 128 bits should be reasonable length. Key lengths of at least 128 bits should be
adequate. The secret key is initialized at system installation time adequate. The secret key is initialized at system installation time
to a pseudo-random number, thus allowing this mechanism to be to a pseudo-random number, thus allowing this mechanism to be
enabled/used automatically, without user intervention. enabled/used automatically, without user intervention.
Including the SLAAC prefix in the PRF computation causes the Including the SLAAC prefix in the PRF computation causes the
Interface ID to vary across networks that employ different prefixes, Interface ID to vary across networks that employ different prefixes,
thus mitigating host-tracking attacks and any other attacks that thus mitigating host-tracking attacks and any other attacks that
benefit from predictable Interface IDs (such as host scanning). benefit from predictable Interface IDs (such as address scanning).
The Interface Index is expected to remain constant across system
reboots and other events. However, we note that it might change upon
removal or installation of a network interface (typically one with a
smaller value for the Interface Index, when such a naming scheme is
used). When such change occurs, the IPv6 addresses resulting from
this algorithm for the corresponding interface will change, thus
affecting the stability property of this method. We note that we
expect these scenarios to be unusual. Some implementations are known
to provide configuration knobs to set the Interface Index for a given
interface. Such configuration knobs could be employed to prevent the
Interface Index from changing (e.g. as a result of the removal of a
network interface).
Including the optional Network_ID parameter when computing the RID Including the optional Network_ID parameter when computing the RID
value above would cause the algorithm to produce a different value above would cause the algorithm to produce a different
Interface Identifier when connecting to different networks, even when Interface Identifier when connecting to different networks, even when
configuring addresses belonging to the same prefix. This means that configuring addresses belonging to the same prefix. This means that
a host would employ a different Interface ID as it moves from one a host would employ a different Interface ID as it moves from one
network to another even for IPv6 link-local addresses or Unique Local network to another even for IPv6 link-local addresses or Unique Local
Addresses (ULAs). Addresses (ULAs).
The DAD_Counter parameter provides the means to intentionally cause
this algorithm produce a different IPv6 addresses (all other
parameters being the same). This could be necessary to resolve
Duplicate Address Detection (DAD) conflicts, as discussed in detail
in Section 4.
4. Resolving Duplicate Address Detection (DAD) conflicts 4. Resolving Duplicate Address Detection (DAD) conflicts
If as a result of performing Duplicate Address Detection (DAD) If as a result of performing Duplicate Address Detection (DAD)
[RFC4862] a host finds that the tentative address generated with the [RFC4862] a host finds that the tentative address generated with the
algorithm specified in Section 3 is a duplicate address, it SHOULD algorithm specified in Section 3 is a duplicate address, it SHOULD
resolve the address conflict by trying a new tentative address as resolve the address conflict by trying a new tentative address as
follows: follows:
o DAD_Counter is incremented by 1. o DAD_Counter is incremented by 1.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
addresses, thus possibly offering an interesting trade-off for those addresses, thus possibly offering an interesting trade-off for those
scenarios in which the use of temporary addresses is not feasible. scenarios in which the use of temporary addresses is not feasible.
7. Acknowledgements 7. Acknowledgements
The algorithm specified in this document has been inspired by Steven The algorithm specified in this document has been inspired by Steven
Bellovin's work ([RFC1948]) in the area of TCP sequence numbers. Bellovin's work ([RFC1948]) in the area of TCP sequence numbers.
The author would like to thank (in alphabetical order) Karl Auer, The author would like to thank (in alphabetical order) Karl Auer,
Steven Bellovin, Matthias Bethke, Brian Carpenter, Tassos Steven Bellovin, Matthias Bethke, Brian Carpenter, Tassos
Chatzithomaoglou, Dominik Elsbroek, Bob Hinden, Christian Huitema, Chatzithomaoglou, Dominik Elsbroek, Brian Haberman, Bob Hinden,
Ray Hunter, Jong-Hyouk Lee, Michael Richardson, and Ole Troan, for Christian Huitema, Ray Hunter, Jong-Hyouk Lee, Michael Richardson,
providing valuable comments on earlier versions of this document. Mark Smith, and Ole Troan, for providing valuable comments on earlier
versions of this document.
This document is based on the technical report "Security Assessment This document is based on the technical report "Security Assessment
of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
Fernando Gont on behalf of the UK Centre for the Protection of Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI). National Infrastructure (CPNI).
Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for
their continued support. their continued support.
8. References 8. References
skipping to change at page 17, line 39 skipping to change at page 17, line 39
can tell whether it is the same device providing some function in two can tell whether it is the same device providing some function in two
different networks, at two different points in time). different networks, at two different points in time).
The scheme proposed in this document prevents such information The scheme proposed in this document prevents such information
leakage by causing nodes to generate different Interface-IDs when leakage by causing nodes to generate different Interface-IDs when
moving to one network to another, thus mitigating this kind of moving to one network to another, thus mitigating this kind of
privacy attack. privacy attack.
A.2. Address scanning attacks A.2. Address scanning attacks
While it is usually assumed that address-scanning attacks are While it is usually assumed that IPv6 address-scanning attacks are
unfeasible, an attacker could leverage patterns in IPv6 addresses to unfeasible, an attacker could leverage patterns in IPv6 addresses to
greatly reduce the search space [I-D.ietf-opsec-ipv6-host-scanning] greatly reduce the search space [I-D.ietf-opsec-ipv6-host-scanning]
[Gont-BRUCON2012]. [Gont-BRUCON2012].
As noted earlier in this document, privacy/temporary addresses do not As noted earlier in this document, privacy/temporary addresses do not
eliminate the use of IPv6 addresses that embed IEEE identifiers, and eliminate the use of IPv6 addresses that embed IEEE identifiers, and
hence such hosts would still be vulnerable to address-scanning hence such hosts would still be vulnerable to address-scanning
attacks. The method specified in this document eliminates such attacks. The method specified in this document eliminates such
patterns and would thus mitigate the aforementioned address-scanning patterns and would thus mitigate the aforementioned address-scanning
attacks. attacks.
 End of changes. 10 change blocks. 
26 lines changed or deleted 51 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/