Network Working Group H. Rafiee INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH C. Meinel Intended status: Informational Hasso Plattner Institute Expires: April 1, 2015 October 1, 2014 Router Advertisement based privacy extension in IPv6 autoconfiguration Abstract The purpose of this document is to address the privacy issues that exist within the Privacy Extension specification and offer an alternative privacy aware solution to correct these shortcomings and also offer an alternative random number generator. 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 http://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 Expires: October 1, 2014. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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 Rafiee, et al. Expires April 1, 2015 [Page 1] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 3 2.1. Duplicate Address Detection (DAD) Process . . . . . . . . 4 3. Advantages of ra-privacy over CGA and DHCPv6 . . . . . . . . 5 4. Interface ID (IID) generation based on the MAC address . . . 5 5. Lifetime of an Interface ID (IID) . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 6 9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Rafiee, et al. Expires April 1, 2015 [Page 2] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 The purpose of this document is to address the privacy issues that exist within the Privacy Extension specification and offer an alternative privacy aware solution for a random number generator to correct these shortcomings. 1. Introduction Today, privacy is an important concern to everyone in their everyday life. In Internet, Privacy is not bound to any particular layer in the Open Systems Interconnection (OSI) model, but some layers do have a greater impact on user?s privacy. This document tries to address the deficiency that exists in the privacy extension specification [RFC4941] as it relates to the network layer. In other words, how an IP address can affect user's privacy. One of the solutions for IPv6 autoconfiguration (RFC 4682) is the use of the Privacy Extension [RFC4941]. The Privacy Extension document explains two different approaches that can be used for IID generation. In the first approach, the use of stable storage enables a node to find which IIDs are currently in use and which are in reserve. In the second approach, where stable storage is not available, it suggests the use of some randomizing approaches and also comments about other available randomizing mechanisms such as Cryptographically Generated Addresses (CGA) [RFC3972] or Dynamic Host Configuration Protocol (DHCPv6). The Privacy Extension document also refers to the use of a named approach as an approach to be used in a mechanism for generating greater randomization. This document aims to introduce a new alternative randomized algorithm to RFC 4941 that can be used in any systems to generate IID not based on the hardware Identifier. This document addresses the following problems: - If the node is changing the physical link, it may keep the IID already used on the link it is leaving, to form an IPv6 address on the new link using SLAAC. Therefore, it negatively impacts user?s privacy and enable tracking a node over the networks. - This document also clarifies the use of other algorithm and compare it with CGA and DHCPv6 when there is no stable storage available. So that the node may be able to make use of a greatly randomized IID because, according to section 3.2.2 of RFC 4941, there is nothing to force the use of RFC 4086. 2. Algorithm Overview This section explains how to make use of a new algorithm that will provide for a higher randomization of the IID without the need for any extra memory or stable storage. This algorithm can be used when there is no stable storage available in the node or the node does not want to store any value in memory. This approach is easy to implement while at the same time provide a good randomization level. Rafiee, et al. Expires April 1, 2015 [Page 3] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 1. Generate a 16 byte random number called modifier. To generate this modifier, implementations should use a random seed to aid in the randomization of this number. 2. Obtain the router prefix from the Router Advertisement message 3. Obtain the nodes' current time in microseconds and call it timestamp. This field consists of a 64-bit, unsigned integer containing the number of milliseconds since January 1, 1970, 00:00 UTC, by using a fixed point format. (Please refer to section 11 for more detail) 4. Concatenate the modifier with the timestamp and the router prefix. R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) Note: Implementations MIGHT skip step 3 and use this timestamp as a seed to PRND function to generate modifier. So, R1 is as follow R1=(modifier(16 bytes)|| router prefix) 5. Execute SHA2 (256) against the result from step 4. digest=SHA256(R1) The use of SHA2 (256) is recommended because the chances of finding a collision are less than when using SHA1 and the generation time is acceptable (in microseconds using a standard CPU). In the future, if a faster and collision free algorithm becomes available, then Implementations need to support it. 6. Take the x bits (leftmost bits or rightmost bits, does not matter and either way is correct) from the resulting output of step 5 (SHA2 digest). x depends on the number of bits that is needed for an IID. Bits u and g do not have any special meaning as in [ugbits]. Note: in case this algorithm is used for only the generation of random number, the next steps should be skipped. 7. Concatenate the IID with the local subnet prefix in order to set the local IP address. If the lifetime of the old local address has not expired, then the node MIGHT skip this step. Otherwise it will receive a new router prefix. 8. Concatenate the IID with the router subnet prefix (Global subnet prefix), obtained from the RA message, and set it as a tentative privacy IP address. This IP address will become permanent after Duplicate Address Detection (DAD) processing. 2.1. Duplicate Address Detection (DAD) Process Rafiee, et al. Expires April 1, 2015 [Page 4] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 After the DAD process has completed, if the node finds collisions in the network, then the modifier will be incremented and the DAD process will be repeated. If, after 3 tries, it receives the same result, it will consider this an attack and will start using that IP address. 3. Advantages of ra-privacy over CGA and DHCPv6 This algorithm has some advantages over the use of CGA and DHCPv6. - CGA generates a highly randomized IID but CGA algorithm is compute intensive. This is the primary reason that CGA algorithm has been only implemented as an experiment but rarely enabled or used in practice. - DHCPv6 server might generates the IIDs sequentially and assign these IIDs to the nodes. This sequential assignment is according to a range of IP addresses and might allow an attacker to scan the nodes in this network and harm their privacy. This is also true, if the node releases an IP address and set new IP address. It is again from the same range. - An administrator needs to configure and maintain DHCPv6 server. This is not needed if a node uses Neighbor Discovery Protocol (NDP). 4. Interface ID (IID) generation based on the MAC address When a node uses the mechanism explained in this document to generate an IID, it must not use any other IID generation approaches that are based on MAC addresses (RFC 4862) for either temporary or non temporary IID generation. The node might use the algorithm explained in [RFC7217] for the generation of a public address that does not make use of EUI-64 or the MAC address for public (global) addresses. The choice of whether or not to list a node's address in the DNS, undisguised, depends on many factors, including the set of applications to be run on the host. Not listing a node's address in the public DNS may afford the node greater privacy, but, at the same time, it may also impair its ability to support certain applications. 5. Lifetime of an Interface ID (IID) The node might make use of the same algorithm and the same lifetime as is explained in RFC 4941, or the node might choose a lifetime based on some other algorithms or policies [LifeTime]. If it uses the lifetime explained in RFC 4941, then it should generate a new IID whenever it is in different network, regardless of the option in the Router Advertisement message to extend this lifetime. This is because, based on Privacy Extension specification, the node does not Rafiee, et al. Expires April 1, 2015 [Page 5] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 change its IID if the option in the router advertisement in new network extend the lifetime of IID. 6. Security Considerations As is explained in the Privacy Extension document. the same approaches are used to maintain security, such as using Secure Neighbor Discovery (SeND)(RFC 3971) or using a monitoring system which would inform the administrator of the status of the network and of any suspended activities in the network. 7. IANA Considerations There is no IANA consideration C++ source code for the comparison of ra-privacy and privacy extension can be found in the following address http://sourceforge.net/u/hrafiee/raprivacy/ci/master/tree/ 8. Acknowledgements The author would like to thank all those people who directly helped in improving this draft especially Andrew Yourtchenko 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture," RFC 4291, February 2006. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)," RFC 3972, March 2005. [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Carney, M. , " Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, Rafiee, et al. Expires April 1, 2015 [Page 6] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC7217] Gont, F., " A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC7217, April 2014 9.2. Informative References [ugbits] Carpenter B., "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014 [LifeTime] Rafiee, H., Meinel, C., Nordmark, E., "Interface ID lifetime Algorithms", https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime, 2013 Rafiee, et al. Expires April 1, 2015 [Page 7] INTERNET DRAFT RA-base Privacy Extension October 1, 2014 Authors' Addresses Hosnieh Rafiee HUAWEI TECHNOLOGIES Duesseldorf GmbH Riesstrasse 25, 80992, Munich, Germany Phone: +49 (0)162 204 74 58 Email: hosnieh.rafiee@huawei.com Christoph Meinel Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Email: meinel@hpi.uni-potsdam.de Rafiee, et al. Expires April 1, 2015 [Page 8]