IPv6 maintenance Working Group (6man) H. Rafiee INTERNET-DRAFT C. Meinel Updates RFC 4941 (if approved) Hasso Plattner Institute Intended status: Proposed Standard Expires: February 12, 2014 August 12, 2013 Router Advertisement based privacy extension in IPv6 autoconfiguration Abstract Privacy is an important issue that concerns many governments and users and its importance becoming more evident every day. Nodes change their IP addresses frequently in order to avoid being tracked by attackers. The act of frequently changing IP addresses also helps in preventing nodes from leaking information. In IPv6 networks there is currently one solution for maintaining the privacy of nodes when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is used. Unfortunately there are some problems associated with this solution which entails the use of the Privacy Extension (RFC 4941). One of the issues with this RFC concerns the wording that is used that allows the implementation to make the choice as to what approach to use, and in so doing, in some cases, the choice made is not the most prudent or best approach, and this thus is not ideal and can lead to some problems. Some of these problems are related to not generating a new Interface ID (IID) after changing the router prefix. Another concern is the fact that nodes may use an IID that was generated based on a MAC address as a public address, and then use this in their response. The act of cutting the current connections to other nodes, if the max lifetime of the old IID has elapsed, is also not clearly explained nor is whether or not the already used IID should be kept in stable storage, There is also a concern about the need to have stable storage available for the generation of a randomized IID. The document also did not clearly explain how to use the same approach, for the random value generation in all implementations, when there is a lack of available stable storage. The purpose of this document is to address these issues; to update the current RFC. 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. Rafiee, et al. Expires February 12, 2014 [Page 1] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 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: February 12, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 4 3.1. Duplicate Address Detection (DAD) Process . . . . . . . . 5 4. Modification to the use of stable storage . . . . . . . . . . 5 5. Interface ID (IID) generation based on the MAC address . . . 6 6. Lifetime of Interface ID (IID) . . . . . . . . . . . . . . . 6 7. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7 11.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Rafiee, et al. Expires February 12, 2014 [Page 2] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 1. Introduction Today, privacy is an important concern to everyone in their everyday life. 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 privacy. This document tries to address the deficiency that exists in the current privacy solution for the network layer. In other words, how an IP address can affect user privacy. The current solution for IPv6 autoconfiguration (RFC 4682) is 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 names as an approach to be used in a mechanism for generating greater randomization. This document addresses the following problems: - RFC 4941 promotes the use of IIDs generated by a MAC address as a public address for the node - The node might not generate a new IID when it receives a new RA message if the option in the router advertisement message tells the node to extend the lifetime of its address. If the maximum lifetime of that address has not been reached, then the node will keep its current IID without generating a new one. - A node may determine a need for the use of a large, stable storage area in which to store each newly generated IID. This needs to be done to prevent the generation of another currently "in use" value. When there is no stable storage available the node may not 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. The Updates pertain to the following sections and concepts in RFC 4941: - Section 3.2.3: in order to explain the use of a new randomization algorithm when stable storage is not available and when implementers are not willing to use RFC 4086. This algorithm can provide the same randomization as does CGA. - An additional update to this RFC will explain how to maintain the lifetime of the IP address when the router prefix changes or the lifetime of the IID, in general, changes. This is needed because, in Rafiee, et al. Expires February 12, 2014 [Page 3] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 this RFC, the lifetime of the IID plays a key role. This means that the node might not change its IID when it moves to another network unless the node is rebooted. This can afford an attacker the ability to track this node, and in doing so, to obtain enough confidential information about this node to assist in further attacks. - Step 4, Section 3.2.1: update to clarify which IIDs should be kept in stable storage. If there is no stable storage available, and if none of the methods explained in RFC 4086 [RFC4086] for randomization are used, then it is possible for the node to make a bad choice as to the approach to use for the randomization process, and, thus, may not be able to make use of a highly randomized IID. This is due to the fact that, in section 3.2.2 of RFC 4941, the word "might" is used in explaining the proper randomization approach to be used. The approach should be specified. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC 2119 significance. In this document the use of || indicates the concatenation of the values on either side of the sign. 3. Algorithm Overview This section explains how to make use of a new algorithm that will provide for higher randomization of the IID without the need for stable storage. This approach is RECOMMENDED, and preferable over the first approach where stable storage is needed, because this approach is easier to use than the stable storage approach. 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 and convert it to a timestamp. The timestamp field consists of a 64-bit, unsigned integer field containing a timestamp whose value is computed from the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point Rafiee, et al. Expires February 12, 2014 [Page 4] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 format. 4. Concatenate the modifier with the timestamp and the router prefix. R1=(modifier(16 bytes)||timestamp(8 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 it SHOULD be used. It is RECOMMENDED that the implementation be able to support any new algorithms. 6. Take the 64 leftmost bits from the resulting output of step 5 (SHA2 digest) and set bits u and g (bits 7 and 8) to one and call this the IID. 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. This constitutes another update to RFC 4941. The status of IP addresses defined in RFC 4941 are temporary, while they SHOULD be permanent with a lifetime as explained in section 4. 3.1. Duplicate Address Detection (DAD) Process 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. 4. Modification to the use of stable storage The stable storage (section 3.2.1 RFC 4941) MUST only contain the last value generated by the node. The node MUST not keep older, already used, IIDs. This modification is made to eliminate the need for large stable storage. For the randomization approach, if the node cannot pick the best algorithm from among the ones already explained Rafiee, et al. Expires February 12, 2014 [Page 5] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 in RFC 4086, then it MUST also include a timestamp in order to preclude the generation of an already used IID. 5. Interface ID (IID) generation based on the MAC address Step 3 in Section 3.3 of RFC 4941 MUST be ignored. 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 SHOULD use the algorithm explained in [StableAddresses] 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. 6. Lifetime of 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. If it uses the lifetime explained in RFC 4941, then it SHOULD generate a new IID whenever it receives a new router prefix, regardless of the option in the Router Advertisement message to extend this lifetime. 7. Threat Analysis By updating RFC 4941, a node will be able to prevent many attacks on users' privacy. A list of these attacks are explained in [privacyConsideration]. 8. 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. 9. IANA Considerations Rafiee, et al. Expires February 12, 2014 [Page 6] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 This document is updating RFC 4941 in order to prevent nodes from using addresses that were generated based on a MAC address and also some of the other deficiencies that exist in RFC 4941 10. Conclusions Privacy has become a very important issue in recent years. There is one solution to privacy issues, but the current solution is deficient in some respects. The purpose of this current document is to address and solve the problem which exists with the Privacy Extension document [RFC4941]. 11. References 11.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, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 11.2. Informative References [StableAddresses] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work In Progress, http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses, 2013 [privacyConsideration] Cooper, A., Gont, F., Thaler, D., "Privacy Considerations for IPv6 Rafiee, et al. Expires February 12, 2014 [Page 7] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 Address Generation Mechanisms", http://tools.ietf.org/html/draft-cooper-6man-ipv6-address-generation-privacy, 2013 Rafiee, et al. Expires February 12, 2014 [Page 8] INTERNET DRAFT RA-base Privacy Extension August 12, 2013 Authors' Addresses Hosnieh Rafiee Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Phone: +49 (0)331-5509-546 Email: ietf@rozanak.com Dr. Christoph Meinel (Professor) Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Email: meinel@hpi.uni-potsdam.de Rafiee, et al. Expires February 12, 2014 [Page 9]