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 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]