Internet DRAFT - draft-gont-6man-non-stable-iids
draft-gont-6man-non-stable-iids
IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Intended status: Standards Track C. Huitema
Expires: September 25, 2018 Private Octopus Inc.
S. Krishnan
Ericsson Research
G. Gont
SI6 Networks
M. Garcia Corbo
SITRANS
March 24, 2018
Recommendation on Temporary IPv6 Interface Identifiers
draft-gont-6man-non-stable-iids-04
Abstract
This document specifies a set of requirements for generating
temporary addresses, and clarifies the stability requirements for
IPv6 addresses, allowing for the use of only temporary addresses.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 25, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Gont, et al. Expires September 25, 2018 [Page 1]
Internet-Draft Temporary Interface-IDs March 2018
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Stability Requirements for IPv6 Addresses . . . . . . . . . . 4
5. Requirements for Temporary IPv6 Addresses . . . . . . . . . . 4
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
IPv6 StateLess Address AutoConfiguration (SLAAC) [RFC4862] has
traditionally resulted in stable addresses, since the Interface
Identifier (IID) has been generated by embedding a stable layer-2
numeric identifier (e.g., a MAC address). [RFC4941] originally
implied, throughout the specification, that temporary addresses are
generated and employed along with stable addresses.
While the use of stable addresses (only) or mixed stable and
temporary addresses can be desirable in a number of scenarios, there
are other scenarios in which, for security and privacy reasons, a
node may want to use only temporary address (e.g., a temporary
address).
On the other hand, the lack of a formal set of requirements for
temporary addresses led to a number of flaws in popular
implementations and in the protocol specification itself, such as
allowing for the correlation of network activity carried out with
different addresses, reusing randomized identifiers across different
networks, etc.
This document clarifies the requirements for stability of IPv6
addresses, such that nodes are not required to configure stable
addresses, and may instead employ only temporary addresses. It also
specifies a set of requirements for the generation of temporary
addresses.
Gont, et al. Expires September 25, 2018 [Page 2]
Internet-Draft Temporary Interface-IDs March 2018
2. Terminology
Statistically different:
When two values are required to be "statistically different", it
means that the equality of those values cannot be caused by
anything else other than random chance.
This document employs the definitions of "stable address" and
"temporary address" from [RFC7721].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Problem statement
When [RFC4941] was written, its authors wanted to prevent privacy and
security attacks enabled by addresses that contain "an embedded
interface identifier, which remains constant over time". They
observed that "Anytime a fixed identifier is used in multiple
contexts, it becomes possible to correlate seemingly unrelated
activity using this identifier." They were concerned with both on-
path attackers who would observe the IP addresses of packets observed
in transit, and attackers that would have access to the logs of
servers.
Since the publication of [RFC4941] in September 2007, our
understanding of threats and mitigations has evolved. The IETF is
now officially concerned with Pervasive Monitoring [RFC7258], as well
as the wide spread collection of information for advertising and
other purposes, for example through the Real Time Bidding protocol
used for advertising auctions [RTB25].
3.1. Privacy requirements
The widespread deployment of encryption advocated in [RFC7624] is a
response to Pervasive Monitoring. Encryption of communication
reduces the amount of information that can be collected by monitoring
data links, but does not prevent monitoring of IPv6 addresses
embedded in clear text packet headers. Stable IPv6 addresses enable
the correlation of such data over time.
MAC Address Randomization [IETFMACRandom] is another response to
pervasive monitoring. In conjunction with DHCP Anonymity [RFC7844],
it ensures that devices cannot be tracked by their MAC Address or
their DHCP identifiers when they connect to "hot spots". However,
the privacy effects of MAC Address Randomization would be nullified
Gont, et al. Expires September 25, 2018 [Page 3]
Internet-Draft Temporary Interface-IDs March 2018
if a device kept using the same IPv6 address before and after a MAC-
address randomization event.
Many Web Browsers have options enabling browsing "in private".
However, if the web connections during the private mode use the same
IPv6 address as those in the public mode, web tracking systems
similar to [RTB25] will quickly find the correlation between the
public personna of the user and the supposedly private connection.
Similarly, many web browsers have options to "delete history",
including deleting "cookies" and other persistent data. Again, if
the same IPv6 address is used before and after the deletion of
cookies, web tracking systems will easily correlate the new activity
with the prior data collection.
Using temporary address alone may not be sufficient to prevent all
forms of tracking. It is however quite clear that some usage of
temporary addresses is necessary to provide user privacy. It is also
clear that the usage of temporary addresses needs to be synchronized
with other privacy defining event such as moving to a new network,
performing MAC Address Randomization, or changing the privacy posture
of a node.
4. Stability Requirements for IPv6 Addresses
Nodes are not required to generate addresses with any specific
stability properties. That is, the generation of stable addresses is
OPTIONAL. This means that a node may end up configuring only stable
addresses, only temporary, or both stable and temporary addresses.
5. Requirements for Temporary IPv6 Addresses
The requirements for temporary IPv6 addresses are as follows:
1. Temporary addresses MUST have a limited lifetime (limited "valid
lifetime" and "preferred lifetime" from [RFC4862]), that should
be statistically different for different addresses. The lifetime
of an address essentially limits the extent to which network
activity correlation can be performed for such address.
2. The lifetime of an address MUST be further reduced when privacy-
meaningful events (such as a node attaching to a new network)
takes place.
3. The resulting Interface Identifiers MUST be statistically
different when addresses are configured for different prefixes.
That is, when temporary addresses are generated for different
autoconfiguration prefixes for the same network interface, the
resulting Interface Identifiers must be statistically different.
Gont, et al. Expires September 25, 2018 [Page 4]
Internet-Draft Temporary Interface-IDs March 2018
This means that, given two addresses that employ different
prefixes, it must be difficult for an outside entity to tell
whether the addresses correspond to the same network interface or
even whether they have been generated by the same host.
4. It must be difficult for an outside entity to predict the
Interface Identifiers that will be employed for temporary
addresses, even with knowledge of the algorithm/method employed
to generate them and/or knowledge of the Interface Identifiers
previously employed for other temporary addresses.
5. The resulting Interface Identifiers MUST be semantically opaque
[RFC7136] and MUST NOT follow any specific patterns.
By definition, temporary addresses have a limited lifetime. This is
in contrast with e.g. stable addresses [RFC7217], that are not
expected to become invalid under normal circumstances. Employing
statistically different lifetimes for different addresses prevents an
observer from synchronizing with the temporary address regeneration;
that is, from being able to predict when a temporary address will
become invalid and a new one regenerated, and thus being able to
infer that one newly observed address is actually the result of
regenerating a previously observed one.
The lifetime of an address should be further reduced by privacy-
meaningful events. For example, a host must not employ the same
address across network attachment events. That is, a host that de-
attaches from a network and subsequently re-attaches to a (possibly
different) network should regenerate all of its temporary addresses.
Similarly, a host that implements MAC address randomization should
regenerate all of its temporary addresses. Failure to regenerate
temporary addresses upon such events would allow the correlation of
network activity across such events (e.g., correlation of network
activity as a host moves from one network to another). Other events,
such as those discussed in Section 3.1 should also trigger the
regeneration of all temporary addresses.
Temporary addresses configured for different prefixes should employ
statistically different interface identifiers. In general, the reuse
of identifiers across different contexts or scopes can be detrimental
for security and privacy [I-D.gont-predictable-numeric-ids] [RFC6973]
[RFC4941]. For example, a node that deterministically employs the
same interface identifier for generating temporary addresses for
different prefixes will allow the correlation of network activity.
For security and privacy reasons, the IIDs generated for temporary
addresses must be unpredictable by an outside entity. Otherwise, the
node may be subject to many (if not all) of the security and privacy
Gont, et al. Expires September 25, 2018 [Page 5]
Internet-Draft Temporary Interface-IDs March 2018
issues that temporary addresses are expected to mitigate (please see
[RFC7721]).
Any semantics or patterns in an IID might be leveraged by an attacker
to e.g. reduce the search space when performing address-scanning
attacks (see [RFC7707], infer the identity of the node, etc.
NOTE:
In the above text, where the "lifetime" of different addresses is
required to be statistically different, or where the interface
identifiers for different temporary addresses is required to be
statistically different, the goal is that an implementation must
not deterministically employ the same such values for different
addresses. For example, where interface identifiers for different
temporary addresses are required to be statistically different,
the goal is to e.g. prevent an implementation from computing a
single random interface identifier and employing such identifier
for the generation of temporary addresses for other prefixes for
the same network interface (as was the case with the algorithm
specified in [RFC4941]). Therefore, a node is neither required
nor expected to e.g. enforce that a newly-generated random
interface identifier is not currently employed by any other
temporary address configured by the node, or that such interface
identifier has not been previously employed for any other
temporary address configured by the node.
6. Future Work
This document clarifies the requirements for stability requirements
for IPv6 addresses, and specifies requirements for temporary
addresses. A separate document
([I-D.gont-taps-address-usage-problem-statement]) discusses the
trade-offs involved when considering different stability properties
of IPv6 addresses.
7. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
8. Security Considerations
This document clarifies the stability requirements for IPv6
addresses, and specifies requirements for the generation of temporary
addresses.
Gont, et al. Expires September 25, 2018 [Page 6]
Internet-Draft Temporary Interface-IDs March 2018
The security and privacy properties of IPv6 addresses have been
discussed in detail in [RFC7721] and [RFC7707].
9. Acknowledgements
The authors would like to thank (in alphabetical order) Brian
Carpenter, Lorenzo Colitti, and David Plonka, for providing valuable
feedback on earlier versions of this document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers",
RFC 5453, DOI 10.17487/RFC5453, February 2009,
<https://www.rfc-editor.org/info/rfc5453>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
Gont, et al. Expires September 25, 2018 [Page 7]
Internet-Draft Temporary Interface-IDs March 2018
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[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>.
10.2. Informative References
[FIPS-SHS]
NIST, "Secure Hash Standard (SHS)", FIPS
Publication 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[I-D.gont-predictable-numeric-ids]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
draft-gont-predictable-numeric-ids-02 (work in progress),
February 2018.
[I-D.gont-taps-address-usage-problem-statement]
Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem
Statement Regarding IPv6 Address Usage", draft-gont-taps-
address-usage-problem-statement-00 (work in progress),
February 2018.
[IANA-RESERVED-IID]
IANA, "Reserved IPv6 Interface Identifiers",
<http://www.iana.org/assignments/ipv6-interface-ids>.
[IETFMACRandom]
Zuniga, JC., "MAC Privacy", November 2014,
<http://www.ietf.org/blog/2014/11/mac-privacy/>.
[OPEN-GROUP]
The Open Group, "The Open Group Base Specifications Issue
7 / IEEE Std 1003.1-2008, 2016 Edition",
Section 4.16 Seconds Since the Epoch, 2016,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
contents.html>.
Gont, et al. Expires September 25, 2018 [Page 8]
Internet-Draft Temporary Interface-IDs March 2018
[RAID2015]
Ullrich, J. and E. Weippl, "Privacy is Not an Option:
Attacking the IPv6 Privacy Extension", International
Symposium on Recent Advances in Intrusion Detection
(RAID), 2015, <https://www.sba-research.org/wp-
content/uploads/publications/Ullrich2015Privacy.pdf>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
DOI 10.17487/RFC3041, January 2001,
<https://www.rfc-editor.org/info/rfc3041>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010,
<https://www.rfc-editor.org/info/rfc6059>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
Gont, et al. Expires September 25, 2018 [Page 9]
Internet-Draft Temporary Interface-IDs March 2018
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
[RTB25] Interactive Advertising Bureau (IAB), "Real Time Bidding
(RTB) project, OpenRTB API Specification Version 2.5",
December 2016, <http://www.iab.com/wp-
content/uploads/2016/03/
OpenRTB-API-Specification-Version-2-5-FINAL.pdf>.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Christian Huitema
Private Octopus Inc.
Friday Harbor, WA 98250
U.S.A.
Email: huitema@huitema.net
URI: http://privateoctopus.com/
Suresh Krishnan
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Email: suresh.krishnan@ericsson.com
Gont, et al. Expires September 25, 2018 [Page 10]
Internet-Draft Temporary Interface-IDs March 2018
Guillermo Gont
SI6 Networks
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: ggont@si6networks.com
URI: https://www.si6networks.com
Madeleine Garcia Corbo
Servicios de Informacion del Transporte
Neptuno 358
Havana City 10400
Cuba
Email: madelen.garcia16@gmail.com
Gont, et al. Expires September 25, 2018 [Page 11]
