One document matched: draft-rafiee-6man-ra-privacy-00.txt

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
                  <draft-rafiee-6man-ra-privacy-00.txt>

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]