IPv6 maintenance Working Group (6man) H. Rafiee INTERNET-DRAFT C. Meinel Updates RFC 4941 Hasso Plattner Institute (if approved) Intended status: Proposed Standard Expires: November 2, 2013 May 2, 2013 Router Advertisement based privacy extension in IPv6 autoconfiguration Abstract Privacy is an important issue for many governments and users where its importance becomes more evident every day. Nodes might change their IP addresses frequently in order to avoid being tracked by attackers and which also results in the prevention of information being leaked from their nodes. In IPv6 networks there is currently one solution for maintaining privacy for nodes when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC-4662) is used. Unfortunately this solution, i.e., Privacy Extension (RFC-4941), has some problems, such as not generating a new Interface ID (IID) after changing the router prefix. The RFC also gives no explanation as to how to use CGA in its randomizing solution. The purpose of this document is to address these issues and 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. 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: November 2, 2013. Copyright Notice Rafiee, et al. Expires November 2, 2013 [Page 1] INTERNET DRAFT RA-base Privacy Extension May 2, 2013 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 . . . . . . . . . . . . . . 3 3. Algorithms Overview . . . . . . . . . . . . . . . . . . . . . 3 4. Lifetime of Interface ID (IID) . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Rafiee, et al. Expires November 2, 2013 [Page 2] INTERNET DRAFT RA-base Privacy Extension May 2, 2013 1. Introduction This document defines the meaning of privacy as it relates to methods for maintaining our confidential data so that it does not become available to or is exposed to unscrupulous people who would use it to harm us or use it for their ill gains. There is currently only one solution available in IPv6 autoconfiguration (RFC-4662), i.e., Privacy Extension [RFC4941]. In the Privacy Extension document, two different approaches are used for IID generation. In the first approach, the use of stable storage enables it to find which IIDs are used and which are reserved. In the second approach, where stable storage is not available, it offers the use of either Cryptographically Generated Addresses (CGA) [RFC3972] or Dynamic Host Configuration Protocol (DHCPv6). The Privacy Extension document also referred to the use of named approaches as a mechanism for greater randomization. Here we offer an update to section 3.2.2 of RFC-4941 in order to explain how to use CGA when security is not the issue. Another update to this RFC will be how to maintain the lifetime of the IP address when the router prefix changes. This is because, in this RFC, the key role is the lifetime of the IID, and it might not expire when the router prefix is changed. This means that the node might not change its IID when it moves to another network unless it is rebooted. This might give an attacker the ability to track this node, and obtain enough confidential information about this node, to allow for further attacks. 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. Algorithms Overview This section explains how to use the modified version of the CGA algorithm for the randomization of the IID. 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. Rafiee, et al. Expires November 2, 2013 [Page 3] INTERNET DRAFT RA-base Privacy Extension May 2, 2013 2. Obtain Router prefix from the router advertisement 3. Obtain the nodes' current time and convert it to timestamp. The timestamp is a 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. 4. Concatenate the modifier to the timestamp and router prefix. R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) 5. Execute SHA2 (256) on 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). If, in the future, 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 from step 5 (SHA2 digest) and set bits u and g (bits 7 and 8) to zero and call this the IID. 7. Concatenate the IID to the local subnet prefix in order to set the local IP address 8. Concatenate the IID to the router subnet prefix (Global subnet prefix), obtained from the RA message, and set it as a tentative global IP address. This IP address will become permanent after Duplicate Address Detection (DAD) processing. 4. Lifetime of Interface ID (IID) One of the problems with the Privacy Extension document as explained earlier is that the IID might not change when the node joins new network or receives a new router prefix. Here we update this document. The router prefix has a higher priority than the IID's current lifetime. This means that the node will receive new router prefix while its current IID is still valid. It MUST generate new randomized IID and start using it. It should not start any new sessions with the old IID, but it MIGHT keep the current sessions as was is explained in the Privacy Extension document. The IIDs MUST only be valid for a short period of time which will depend on the network policy in vogue. Any implementations SHOULD provide a means of allowing for users to change the lifetime default value. 5. Security Considerations Rafiee, et al. Expires November 2, 2013 [Page 4] INTERNET DRAFT RA-base Privacy Extension May 2, 2013 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. 6. IANA Considerations - 7. Conclusions Privacy has become a very important issue in recent years. There is one solution to the privacy issues, but the current solution has some deficiencies. The purpose of the current document is to address and solve the problem which exists with the Privacy Extension document [RFC4941]. 8. References 8.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. Rafiee, et al. Expires November 2, 2013 [Page 5] INTERNET DRAFT RA-base Privacy Extension May 2, 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 November 2, 2013 [Page 6]