IPv6 maintenance Working Group (6man) H. Rafiee INTERNET-DRAFT C. Meinel Updates RFC 4941 (if approved) Hasso Plattner Institute Intended status: Proposed Standard Expires: November 14, 2013 May 14, 2013 Router Advertisement based privacy extension in IPv6 autoconfiguration Abstract Privacy is an important issue concerning many governments and users with its importance becoming more evident every day. Nodes might change their IP addresses frequently in order to avoid being tracked by attackers. This frequent IP address change also helps in the prevention of information being leaked by nodes. In IPv6 networks there is currently one solution to maintain the privacy of nodes when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4662) is used. Unfortunately there are some problems associated with this solution which entails the use of the Privacy Extension (RFC 4941). Some of these problems are not generating a new Interface ID (IID) after changing the router prefix, the fact that nodes may use an IID that was generated based on a MAC address and 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, and a need to have stable storage for generating a randomized IID. The RFC also gives no explanation as to how to use CGA in its randomizing solution when stable storage is not available. 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 14, 2013. Rafiee, et al. Expires November 14, 2013 [Page 1] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 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 . . . . . . . . . . . . . . 3 3. Algorithms Overview . . . . . . . . . . . . . . . . . . . . . 4 3.1. Duplicate Address Detection (DAD) Process . . . . . . . . 5 4. Interface ID (IID) generation based on the MAC address . . . 5 5. Lifetime of Interface ID (IID) . . . . . . . . . . . . . . . 5 5.1. Automate the process for setting the lifetime . . . . . . 6 6. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Location based tracking . . . . . . . . . . . . . . . . . 6 6.2. Obtaining confidential data . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Rafiee, et al. Expires November 14, 2013 [Page 2] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 1. Introduction Privacy and security have a close relationship. Privacy, simply stated, is the act of allowing a user to choose which data he wants to make available to others or which data he wants to keep from others. Security, on the other hand, is the ability to protect your data or to keep your data confidential. There are times, however, where one will have to be sacrificed for the sake of the other. The gathering of location information for security reasons might prove detrimental to privacy. But in many cases, when cryptography or other approaches are used to protect the content of the data, you are not only securing them but also providing privacy. 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 to use it for their ill gains. There is currently only one solution available in IPv6 autoconfiguration (RFC-4662) which is the, 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 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 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. An additional update to this RFC will explain how to maintain the lifetime of the IP address when the router prefix changes. This is needed because, in this RFC, the key role is the lifetime of the IID, which 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 the node is rebooted. This can afford an attacker the ability to track this node, and obtain enough confidential information about this node, to allow for further attacks. The third problem occurs if the node responds to the request from other nodes using the IID generated based on the MAC address. This could happen if the RFC does not force the node to use only the IID generated using this approach. The forth problem can occur when the node cuts current connections to other nodes because the maximum lifetime for this IID has expired. Finally, a node may require a large stable storage area in which to store each generated IID to preclude the use of an already used value. If there is no stable storage available, the node may not be able to make use of a greatly randomized IID. 2. Conventions used in this document Rafiee, et al. Expires November 14, 2013 [Page 3] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 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 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. In this approach the node will not need to maintain a large space. 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 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 Rafiee, et al. Expires November 14, 2013 [Page 4] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 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 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. This is another update to RFC 4941. The status of IP addresses in RFC 4941 are temporary while it SHOULD be permanent with a life time explained in section 4. 3.1. Duplicate Address Detection (DAD) Process After the DAD process, if the node finds collisions in the network then the modifier will be incremented and the DAD process will be repeated. If after 3 times, it receives the same result, it will consider this an attack and will start using that IP address. 4. Interface ID (IID) generation based on the MAC address When a node uses the mechanism explained in this document for IID generation, it MUST not use any other IID generation approaches, especially those approaches based on MAC addresses. For debugging and trouble shooting purposes, the implementation MUST provide a means of partially disabling the mechanism explained in this document. Allowing for manually setting and unsettling a flag, which would indicate the debugging mode, is one way to accomplish this. This means that when this flag is set, the node SHOULD not generate any new IIDs and SHOULD change the lifetime for this IID to a large number. As soon as trouble shooting ends and the flag is set back to zero, then the node MUST generate a new IID and start using it. The lifetime of the old IID must also be set to an appropriate value at this time. 5. 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 if the node receives new router prefix while its current IID is still valid, it MUST generate new randomized IID and start using it. 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. Rafiee, et al. Expires November 14, 2013 [Page 5] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 Another problem that occurs with the use of this Privacy Extension document is that the node will cut its current connections to the other nodes using this IID when the maximum lifetime of the IID expires, The update to that document will state that the node can maintain its old connections with its old IID for a certain period of time, but not an indefinite period of time, and it MUST not start any new connections using the old IID. In cases where the router prefix changes, the node SHOULD cut the connection. If for any reason there is a need to maintain the old connections, this document RECOMMENDS the use of Mobile IPv6 (RFC 6275). 5.1. Automate the process for setting the lifetime The implementations MIGHT consider an option where the RA messages update the lifetime of all addresses generated when using this approach when processing RA messages. This will eliminate the need for the manual step during installation which sets the default value of lifetime for any future IIDs generated using this approach based on network policy. The format for this lifetime value will be the same as that explained in section 5.3.1 RFC 3971. In this lifetime option the type for SHOULD be set to next sequential number available in the SeND options, i.e., 15. This field SHOULD be added to the ICMPv6 option of RA messages. 6. Threat Analysis Privacy consists of personal data that is any information relating to an individual, whether it relates to his or her private, professional or public life. It can be anything from a name, a photo, an email address, bank details, his posts on social networking websites, his medical information, or his computer's IP address. Any unauthorized efforts to obtain this information is considered an attack against a user's privacy. The following sections will explain how the mechanism detailed in this document can protect a user's privacy. 6.1. Location based tracking As the node MUST keep its IID for only a short period of time, and MUST also change it when the prefix changes, it is not very easy for an attacker to track this node based on its IP address. This is also the case when the node changes the IID within the same network. The reason for this is because it is very difficult for the attacker to realize that this node is the same node only with a newly generated IID. This is especially true when there is an unlimited number of nodes on the same network. Rafiee, et al. Expires November 14, 2013 [Page 6] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 6.2. Obtaining confidential data When a node changes its IID frequently within the network and among networks, the attacker probably won't have enough time to obtain the user's confidential data. It will also be difficult for the attacker to correlate the information that he does obtain to a specific user's IP address. This means that it will be difficult for the attacker to obtain more information about this user based on any correlation of data. An example would be when an attacker obtains a confidential document from a user but he is unsure about the location of this user. If the attacker had the location the user, he would be able to obtain much more information about this use, and then he would be abler to start the attacks against him. But changing the IID prevents the attacker from finding the location of this user and thus prevents further attacks. 7. 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. 8. IANA Considerations - 9. 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]. 10. References 10.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. Rafiee, et al. Expires November 14, 2013 [Page 7] INTERNET DRAFT RA-base Privacy Extension May 14, 2013 [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 14, 2013 [Page 8] INTERNET DRAFT RA-base Privacy Extension May 14, 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 14, 2013 [Page 9]