[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IPv6 Operations Working Group (v6ops)                         H. Rafiee
INTERNET-DRAFT                                                C. Meinel
Intended status: Proposed Informational         Hasso Plattner Institute
                                                             E. Nordmark
                                                         Arista Networks
Expires: April 21, 2014                                 October 21, 2013


                    Interface ID lifetime Algorithms
                <draft-rafiee-v6ops-iid-lifetime-00.txt>

Abstract

   This document introduces a framework, i.e., an application layer
   based lifetime [applicationiid] to enable applications maintaining
   their users' privacy as well as controlling the number of Interface
   IDs (IIDs) per network adapter. It will also explain different
   approaches that can be used for maintaining the lifetime of an IID.
   We also compare this framework to the other available mechanisms.
   This document also explains when to remove deprecated IP addresses
   from the a network interface.



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: February 10, 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


Rafiee, et al.       Expires April 21, 2014                     [Page 1]


INTERNET DRAFT                            IID lifetime  October 21, 2013

   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
     1.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Generation of an Interface ID  . . . . . . . . . . . . . . . .  4
   5.  Lifetime Explained in RFC 4941   . . . . . . . . . . . . . . .  4
   6.  Connection Based Lifetime (layer-4)  . . . . . . . . . . . . .  4
   7.  Application Layer based Lifetime for the Interface ID (IID)  .  5
     7.1.  Configuring the Default values   . . . . . . . . . . . . .  6
       7.1.1.  Deprecated Interface ID  . . . . . . . . . . . . . . .  7
       7.1.2.  Configuring Default values   . . . . . . . . . . . . .  7
     7.2.  Receiving more than one RA message   . . . . . . . . . . .  7
     7.3.  Automate the process for setting the lifetime  . . . . . .  7
   8.  Threat Analysis of Application Layer based lifetime  . . . . .  8
     8.1.  Location based tracking  . . . . . . . . . . . . . . . . .  8
     8.2.  Obtaining confidential data  . . . . . . . . . . . . . . .  8
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   10.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  8
   11.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  9
   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     12.1.  Normative . . . . . . . . . . . . . . . . . . . . . . . .  9
     12.2.  Informative . . . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11




















Rafiee, et al.       Expires April 21, 2014                     [Page 2]


INTERNET DRAFT                            IID lifetime  October 21, 2013



1.  Introduction

   The primary use of Network Address Translation (NAT) (RFC 4787), in
   IPv4, is to address IPv4 exhaustion address space. NAT made the
   companies and places to use other approaches in order to collect more
   information about their users for advertisement or other purposes.
   Browsers' cookie is one example of these mechanisms. To address this
   problem and protect user's privacy, some Internet browsers offer the
   use of "incognito mode" or "private browsing". In this mode, the
   browser does not store any cookies or it will remove all user's
   information as soon as the user closes its browser.

   Today, IPv6 large address space, reduces the need of using NAT. IPv6
   also solves the problem of end-to-end communication. This is because
   the IP addresses used by nodes are globally valid and can be used to
   directly connect to other nodes via the Internet. This means that it
   is easier for advertisement companies to distinguish their users only
   by their unique IP addresses. This is also gives this ability to
   attackers to obtain user's information by using simple approaches
   such as creating a fake website and use it as trap to find the user's
   IP addresses.

   One possible solution might be the use of temporary Interface ID
   (IID). It might be the future capability of the browsers, in
   "incognito mode", not only to prevent storing user's information but
   also generate a new IID for user's connection. However, this might be
   a good solution to maintain user's privacy but it might be
   problematic, especially, if many applications wants to generate their
   IIDs themselves and start a connection. There will be no control over
   the number of valid IIDs. To address this issue, we introduce a
   framework, i.e., an application layer based privacy that can enable
   the applications to request for IIDs without involving in detail of
   IID generation (network layer). This document also introduces
   different mechanisms that may be used in order to maintain the
   lifetime of an Interface ID (IID) used in IPv6 networks. It then
   explain the deficiencies exist in these mechanisms.



1.1.  Problem Statement

   Increase the difficulty of correlating a user's activities by using
   different IIDs for different applications, without negatively
   impacting the robustness of the applications. Since there is some
   network overhead associated with each host having lots of IIDs at the
   same time, the mechanism needs to limit the number of IIDs that are
   in use at any given time.



2.  Conventions used in this document


Rafiee, et al.       Expires April 21, 2014                     [Page 3]


INTERNET DRAFT                            IID lifetime  October 21, 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.  Terminology

   - application : An application is a process in a system, which
   includes all other dependent processes. Usually when an application,
   such as a Firefox browser, is opened in a system, there are many
   other processes that are called into play by this application. The
   meaning of application, as used in this document, is to consider the
   application, itself, including all of its dependent processes.



4.  Generation of an Interface ID

   This document assumes that the node generates its temporary IID by
   using any available algorithm as explained in [RFC4941],
   [StableAddresses], [RFC3972], [ra-privacy], [ssas], etc.



5.  Lifetime Explained in RFC 4941

   There are some variables in play for maintaining the lifetime of an
   IID. There should be no more than one valid IID per network
   interface, at any one time. The preferred lifetime for this IID is
   one day and the maximum lifetime is one week. One drawback to using
   this lifetime IID is that the length of time the IIDs remain in use
   after expiration of the lifetime ( deprecated IIDs) is left solely up
   to the implementers. This means that it is possible for a node to cut
   its connections to other nodes after the expiration of the maximum
   lifetime for that IID. This act could possibly cause problems for any
   applications that are still using that ID.



6.  Connection Based Lifetime (layer-4)

   One possible way of maintaining the lifetime of an IID is connection
   based, i.e., as long as the connection is active, the node keeps this
   IID. The drawback to using this approach is that this may prove


Rafiee, et al.       Expires April 21, 2014                     [Page 4]


INTERNET DRAFT                            IID lifetime  October 21, 2013

   problematic for ftp and other applications that use different layers
   and open different connections.



7.  Application Layer based Lifetime for the Interface ID (IID)

   Another possible way of maintaining the lifetime of an IID is
   application layer based. Figure 1 depicts the algorithm used to
   determine the lifetime of an IID. The use of this algorithm minimizes
   the chance of an attacker being able to obtain a user's private
   information.



           start
             +
             v
   +-------------------+    +--------+
   |new Router prefix  |Yes |c_IID=0 |+------------+
   |       received?   +--->|L_i=0   |             |
   +---------+---------+    +--------+             |
             |No                                   |
             v           +--------------------+    |
     +---------------+   | Find_largest(L_i)  |    |
     |max_IID > c_IID+-->| t_app_i ++         |    |
     +-------+-------+ No| Assign(IID_i,app_i)|    |
             | Yes       +--------------------+    |
     +-------v----------+------------+             |
     |   n_i < t_app_i  +       No   |             |
     +-------+----------+  +---------v----------+  |
        Yes  |             | Generate_New(IID)  |  |
 +-----------v--------+    | c_IID ++           <--+
 | Find_largest(L_i)  |    | Assign(IID_i,app_i)|
 | Assign(IID_i,app_i)|    +--------------------+
 | n_i ++             |
 +--------------------+


   An IID is assigned to a group of applications and this IID is valid
   for the length of time that its lifetime is valid. After that time
   expires the state of this IID is changed to deprecated. This
   deprecated IID can not be assigned to new applications, but it will
   remain valid for as long as any application is using it. The lifetime
   that the deprecated IID should have is explained in section 6.2.

   - app_i is a new application that has been initiated by the node

   - t_app is the maximum number of applications per IID

   - L is the maximum lifetime of an IID

   - max_IID is the maximum number of valid IIDs


Rafiee, et al.       Expires April 21, 2014                     [Page 5]


INTERNET DRAFT                            IID lifetime  October 21, 2013


   - c_IID is the current number of IIDs

   - IID_i is a specific IID

   - t_app_i is the total number of applications allowed per specific
   IID

   - n_i is the current number of applications for a specific IID

   - L_i is the current lifetime of a specific IID

   When a node wants to start a new application, it first checks to see
   whether or not it has also received a new router advertisement
   message. In the case where a new router advertisement message is
   received, the node sets the total lifetime for the current valid IID
   to zero and resets the c_IID to zero. In this case, all of the
   current IIDs associated with this node MUST have expired and the node
   MUST generate, and use,new IIDs for any upcoming applications. But
   the node can still use an expired IID as long as the current
   applications using them are active. (Please refer to section 7.1.1
   for more detail)

   If the node does not receive a new router advertisement message, then
   it checks to see whether or not the current number of IIDs is less
   than the maximum number of IIDs allowed. If the condition is met, the
   node then checks to see whether or not there are any IIDs where the
   current number of applications, n_i , is less than the total number
   of applications, t_app_i. If the condition is met the node SHOULD
   sort these IIDs based on their current lifetime, L_i, in descending
   order, and then assign app_i to the IID with the higher L_i. The
   current number of applications, n_i, for this specific IID is then
   incremented. If n_i is equal to t_app_i, then the node generates a
   new IID and assigns this application to this new IID.

   In cases where the current number of IIDs is equal to the max_IID,
   and n_i is equal to t_app, then the node will be unable to generate a
   new IID for the application nor will it be able to assign a current
   IID to the application. In this case the node SHOULD find the IID
   with the longest lifetime and then increase the total number of
   applications, t_app_i, that can be assigned to it. The node then
   assigns this IID to the new application. The advantage to using this
   algorithm, with regard to the IID lifetime, is that it allows for the
   control of the number of valid IIDs while,at the same time, allowing
   users to keep their current application layer connections. This
   results in user satisfaction.



7.1.  Configuring the Default values

   If the implementation wants to implement this mechanism, they SHOULD
   consider a mechanism to allow applications send their IID request to


Rafiee, et al.       Expires April 21, 2014                     [Page 6]


INTERNET DRAFT                            IID lifetime  October 21, 2013

   the framework.



7.1.1.  Deprecated Interface ID

   A Deprecated IID is an IID that is no longer valid but can still be
   used by any current applications that are running. It is RECOMMENDED
   to remove deprecated IIDs when the node's Operating System (OS)
   reboots or when there is no application using it for 5 minutes (no
   sockets). The maximum period of time that a deprecated IID can be
   valid is one month. Implementers should consider a way of giving
   users a means of setting a new default value.



7.1.2.  Configuring Default values

   - t_app =20

   - L= 10 days

   - max_IID = 10

   - t_app_i = t_app at the start of the application layer lifetime IID
   and SHOULD incremented this if the maximum number of IIDs is equal to
   current number of IIDs, as explained in the algorithm.



7.2.  Receiving more than one RA message

   If a node receives an RA message it will assign an IID to the
   application or to the group of applications as described above. If,
   after a short period of time, another RA message is received, but
   with a different prefix ,and if this router prefix is not in his list
   of the routers in his cache, then the node SHOULD send a Router
   Solicitation (RS) message. If it received more than one RA message
   with different prefixes then it SHOULD assume that these routers are
   in the same network. The maximum number of valid IIDs per router
   prefix is calculated using the following formula:

   Max IID per router prefix=max_IID/(number of routers). This mitigates
   the problem of multicast groups in the network as the maximum number
   of IIDs will never increase, regardless of number of routers in the
   network.



7.3.  Automate the process for setting the lifetime

   The implementations MIGHT consider an option where, when RA messages
   are being processed , the RA message can be used to update the


Rafiee, et al.       Expires April 21, 2014                     [Page 7]


INTERNET DRAFT                            IID lifetime  October 21, 2013

   lifetime for all the addresses that are generated using this
   approach. This will eliminate the need for the manual step, used
   during installation, to set the default value for the lifetime (based
   on network policy) for any future IIDs generated using this approach.
   The format for this lifetime value will be the same as that explained
   in section 5.3.1 RFC 3971. The "type" SHOULD be set to the next
   sequential number available in the SeND options, i.e., 15. When use
   is made of the lifetime option, this field SHOULD be added to the
   ICMPv6 option for RA messages.



8.  Threat Analysis of Application Layer based lifetime



8.1.  Location based tracking

   Similar to the mechanism explained in RFC 4941 and [Ra-privacy], the
   attacker might not have enough time to track the node. This is
   because the IID is valid for only a short period of time and will
   change when a new RA message is received. Since the IIDs are valid
   for a short period of time, storing them using trap websites also
   will not help the attackers because it will be changed after a while.



8.2.  Obtaining confidential data

   If for any reason one of the applications in use on this node exposed
   the users' real IP address to an attacker, the attacker might not be
   able to obtain other confidential information related to other user
   applications on this node. This is because this IID is only used for
   certain purposes and for certain applications. This IID is also valid
   for only a short period of time, and so, the attacker might not have
   enough time to obtain confidential information about this node.%h2





9.  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.



10.  IANA Considerations



Rafiee, et al.       Expires April 21, 2014                     [Page 8]


INTERNET DRAFT                            IID lifetime  October 21, 2013

   No IANA actions are needed for this document.



11.  Conclusions

   This document explained different mechanisms used for maintaining the
   lifetime of an IID. It introduced an application layer based lifetime
   as a solution for the lifetime used for temporary IIDs in order to
   satisfy users needs and to not force them to cut their connections or
   to not open a new connection with an application using a new IID that
   could prove problematic for the application.



12.  References

12.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to
             Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy
             Extensions for Stateless Address Autoconfiguration in
             IPv6", RFC 4941, September 2007.

   [RFC3972] Aura, T., "Cryptographically Generated Addresses
             (CGA)", RFC 3972, March 2005.

12.2.  Informative References

   [ssas] Rafiee, H., Meinel, C., "A Simple Secure Addressing
          Scheme for IPv6 AutoConfiguration", Work In Progress,
          http://tools.ietf.org/html/draft-rafiee-6man-ssas, July, 2013

   [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,
                     August 2013

   [ra-privacy] Rafiee, H., Meinel, C., "Router
                Advertisement based privacy extension in IPv6
                autoconfiguration", Work In
                Progress,http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy,
                July, 2013

   [applicationiid] Rafiee, H., Meinel, C., "Privacy
                    and Security in IPv6 Networks: Challenges and
                    Possible Solution". The 6th International Conference
                    on Security of Information and Networks, ACM,
                    November 2013


Rafiee, et al.       Expires April 21, 2014                     [Page 9]


INTERNET DRAFT                            IID lifetime  October 21, 2013
























































Rafiee, et al.       Expires April 21, 2014                    [Page 10]


INTERNET DRAFT                            IID lifetime  October 21, 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


      Erik Nordmark
      Arista Networks
      Santa Clara, CA
      USA
      Email: nordmark@acm.org


      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 April 21, 2014                    [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/