idnits 2.17.1 draft-rafiee-v6ops-iid-lifetime-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'Ra-privacy' is mentioned on line 327, but not defined ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) H. Rafiee 3 INTERNET-DRAFT C. Meinel 4 Intended status: Proposed Informational Hasso Plattner Institute 5 E. Nordmark 6 Arista Networks 7 Expires: April 21, 2014 October 21, 2013 9 Interface ID lifetime Algorithms 10 12 Abstract 14 This document introduces a framework, i.e., an application layer 15 based lifetime [applicationiid] to enable applications maintaining 16 their users' privacy as well as controlling the number of Interface 17 IDs (IIDs) per network adapter. It will also explain different 18 approaches that can be used for maintaining the lifetime of an IID. 19 We also compare this framework to the other available mechanisms. 20 This document also explains when to remove deprecated IP addresses 21 from the a network interface. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute working 30 documents as Internet-Drafts. The list of current Internet-Drafts is 31 at http://datatracker.ietf.org/drafts/current. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on Expires: February 10, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. This document is subject to 44 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 45 Documents (http://trustee.ietf.org/license-info) in effect on the 46 date of publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Generation of an Interface ID . . . . . . . . . . . . . . . . 4 60 5. Lifetime Explained in RFC 4941 . . . . . . . . . . . . . . . 4 61 6. Connection Based Lifetime (layer-4) . . . . . . . . . . . . . 4 62 7. Application Layer based Lifetime for the Interface ID (IID) . 5 63 7.1. Configuring the Default values . . . . . . . . . . . . . 6 64 7.1.1. Deprecated Interface ID . . . . . . . . . . . . . . . 7 65 7.1.2. Configuring Default values . . . . . . . . . . . . . 7 66 7.2. Receiving more than one RA message . . . . . . . . . . . 7 67 7.3. Automate the process for setting the lifetime . . . . . . 7 68 8. Threat Analysis of Application Layer based lifetime . . . . . 8 69 8.1. Location based tracking . . . . . . . . . . . . . . . . . 8 70 8.2. Obtaining confidential data . . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 12.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 9 76 12.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The primary use of Network Address Translation (NAT) (RFC 4787), in 82 IPv4, is to address IPv4 exhaustion address space. NAT made the 83 companies and places to use other approaches in order to collect more 84 information about their users for advertisement or other purposes. 85 Browsers' cookie is one example of these mechanisms. To address this 86 problem and protect user's privacy, some Internet browsers offer the 87 use of "incognito mode" or "private browsing". In this mode, the 88 browser does not store any cookies or it will remove all user's 89 information as soon as the user closes its browser. 91 Today, IPv6 large address space, reduces the need of using NAT. IPv6 92 also solves the problem of end-to-end communication. This is because 93 the IP addresses used by nodes are globally valid and can be used to 94 directly connect to other nodes via the Internet. This means that it 95 is easier for advertisement companies to distinguish their users only 96 by their unique IP addresses. This is also gives this ability to 97 attackers to obtain user's information by using simple approaches 98 such as creating a fake website and use it as trap to find the user's 99 IP addresses. 101 One possible solution might be the use of temporary Interface ID 102 (IID). It might be the future capability of the browsers, in 103 "incognito mode", not only to prevent storing user's information but 104 also generate a new IID for user's connection. However, this might be 105 a good solution to maintain user's privacy but it might be 106 problematic, especially, if many applications wants to generate their 107 IIDs themselves and start a connection. There will be no control over 108 the number of valid IIDs. To address this issue, we introduce a 109 framework, i.e., an application layer based privacy that can enable 110 the applications to request for IIDs without involving in detail of 111 IID generation (network layer). This document also introduces 112 different mechanisms that may be used in order to maintain the 113 lifetime of an Interface ID (IID) used in IPv6 networks. It then 114 explain the deficiencies exist in these mechanisms. 116 1.1. Problem Statement 118 Increase the difficulty of correlating a user's activities by using 119 different IIDs for different applications, without negatively 120 impacting the robustness of the applications. Since there is some 121 network overhead associated with each host having lots of IIDs at the 122 same time, the mechanism needs to limit the number of IIDs that are 123 in use at any given time. 125 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC-2119 [RFC2119]. 130 In this document, these words will appear with that interpretation 131 only when in ALL CAPS. Lower case uses of these words are not to be 132 interpreted as carrying RFC 2119 significance. 134 In this document the use of || indicates the concatenation of the 135 values on either side of the sign. 137 3. Terminology 139 - application : An application is a process in a system, which 140 includes all other dependent processes. Usually when an application, 141 such as a Firefox browser, is opened in a system, there are many 142 other processes that are called into play by this application. The 143 meaning of application, as used in this document, is to consider the 144 application, itself, including all of its dependent processes. 146 4. Generation of an Interface ID 148 This document assumes that the node generates its temporary IID by 149 using any available algorithm as explained in [RFC4941], 150 [StableAddresses], [RFC3972], [ra-privacy], [ssas], etc. 152 5. Lifetime Explained in RFC 4941 154 There are some variables in play for maintaining the lifetime of an 155 IID. There should be no more than one valid IID per network 156 interface, at any one time. The preferred lifetime for this IID is 157 one day and the maximum lifetime is one week. One drawback to using 158 this lifetime IID is that the length of time the IIDs remain in use 159 after expiration of the lifetime ( deprecated IIDs) is left solely up 160 to the implementers. This means that it is possible for a node to cut 161 its connections to other nodes after the expiration of the maximum 162 lifetime for that IID. This act could possibly cause problems for any 163 applications that are still using that ID. 165 6. Connection Based Lifetime (layer-4) 167 One possible way of maintaining the lifetime of an IID is connection 168 based, i.e., as long as the connection is active, the node keeps this 169 IID. The drawback to using this approach is that this may prove 170 problematic for ftp and other applications that use different layers 171 and open different connections. 173 7. Application Layer based Lifetime for the Interface ID (IID) 175 Another possible way of maintaining the lifetime of an IID is 176 application layer based. Figure 1 depicts the algorithm used to 177 determine the lifetime of an IID. The use of this algorithm minimizes 178 the chance of an attacker being able to obtain a user's private 179 information. 181 start 182 + 183 v 184 +-------------------+ +--------+ 185 |new Router prefix |Yes |c_IID=0 |+------------+ 186 | received? +--->|L_i=0 | | 187 +---------+---------+ +--------+ | 188 |No | 189 v +--------------------+ | 190 +---------------+ | Find_largest(L_i) | | 191 |max_IID > c_IID+-->| t_app_i ++ | | 192 +-------+-------+ No| Assign(IID_i,app_i)| | 193 | Yes +--------------------+ | 194 +-------v----------+------------+ | 195 | n_i < t_app_i + No | | 196 +-------+----------+ +---------v----------+ | 197 Yes | | Generate_New(IID) | | 198 +-----------v--------+ | c_IID ++ <--+ 199 | Find_largest(L_i) | | Assign(IID_i,app_i)| 200 | Assign(IID_i,app_i)| +--------------------+ 201 | n_i ++ | 202 +--------------------+ 204 An IID is assigned to a group of applications and this IID is valid 205 for the length of time that its lifetime is valid. After that time 206 expires the state of this IID is changed to deprecated. This 207 deprecated IID can not be assigned to new applications, but it will 208 remain valid for as long as any application is using it. The lifetime 209 that the deprecated IID should have is explained in section 6.2. 211 - app_i is a new application that has been initiated by the node 213 - t_app is the maximum number of applications per IID 215 - L is the maximum lifetime of an IID 217 - max_IID is the maximum number of valid IIDs 218 - c_IID is the current number of IIDs 220 - IID_i is a specific IID 222 - t_app_i is the total number of applications allowed per specific 223 IID 225 - n_i is the current number of applications for a specific IID 227 - L_i is the current lifetime of a specific IID 229 When a node wants to start a new application, it first checks to see 230 whether or not it has also received a new router advertisement 231 message. In the case where a new router advertisement message is 232 received, the node sets the total lifetime for the current valid IID 233 to zero and resets the c_IID to zero. In this case, all of the 234 current IIDs associated with this node MUST have expired and the node 235 MUST generate, and use,new IIDs for any upcoming applications. But 236 the node can still use an expired IID as long as the current 237 applications using them are active. (Please refer to section 7.1.1 238 for more detail) 240 If the node does not receive a new router advertisement message, then 241 it checks to see whether or not the current number of IIDs is less 242 than the maximum number of IIDs allowed. If the condition is met, the 243 node then checks to see whether or not there are any IIDs where the 244 current number of applications, n_i , is less than the total number 245 of applications, t_app_i. If the condition is met the node SHOULD 246 sort these IIDs based on their current lifetime, L_i, in descending 247 order, and then assign app_i to the IID with the higher L_i. The 248 current number of applications, n_i, for this specific IID is then 249 incremented. If n_i is equal to t_app_i, then the node generates a 250 new IID and assigns this application to this new IID. 252 In cases where the current number of IIDs is equal to the max_IID, 253 and n_i is equal to t_app, then the node will be unable to generate a 254 new IID for the application nor will it be able to assign a current 255 IID to the application. In this case the node SHOULD find the IID 256 with the longest lifetime and then increase the total number of 257 applications, t_app_i, that can be assigned to it. The node then 258 assigns this IID to the new application. The advantage to using this 259 algorithm, with regard to the IID lifetime, is that it allows for the 260 control of the number of valid IIDs while,at the same time, allowing 261 users to keep their current application layer connections. This 262 results in user satisfaction. 264 7.1. Configuring the Default values 266 If the implementation wants to implement this mechanism, they SHOULD 267 consider a mechanism to allow applications send their IID request to 268 the framework. 270 7.1.1. Deprecated Interface ID 272 A Deprecated IID is an IID that is no longer valid but can still be 273 used by any current applications that are running. It is RECOMMENDED 274 to remove deprecated IIDs when the node's Operating System (OS) 275 reboots or when there is no application using it for 5 minutes (no 276 sockets). The maximum period of time that a deprecated IID can be 277 valid is one month. Implementers should consider a way of giving 278 users a means of setting a new default value. 280 7.1.2. Configuring Default values 282 - t_app =20 284 - L= 10 days 286 - max_IID = 10 288 - t_app_i = t_app at the start of the application layer lifetime IID 289 and SHOULD incremented this if the maximum number of IIDs is equal to 290 current number of IIDs, as explained in the algorithm. 292 7.2. Receiving more than one RA message 294 If a node receives an RA message it will assign an IID to the 295 application or to the group of applications as described above. If, 296 after a short period of time, another RA message is received, but 297 with a different prefix ,and if this router prefix is not in his list 298 of the routers in his cache, then the node SHOULD send a Router 299 Solicitation (RS) message. If it received more than one RA message 300 with different prefixes then it SHOULD assume that these routers are 301 in the same network. The maximum number of valid IIDs per router 302 prefix is calculated using the following formula: 304 Max IID per router prefix=max_IID/(number of routers). This mitigates 305 the problem of multicast groups in the network as the maximum number 306 of IIDs will never increase, regardless of number of routers in the 307 network. 309 7.3. Automate the process for setting the lifetime 311 The implementations MIGHT consider an option where, when RA messages 312 are being processed , the RA message can be used to update the 313 lifetime for all the addresses that are generated using this 314 approach. This will eliminate the need for the manual step, used 315 during installation, to set the default value for the lifetime (based 316 on network policy) for any future IIDs generated using this approach. 317 The format for this lifetime value will be the same as that explained 318 in section 5.3.1 RFC 3971. The "type" SHOULD be set to the next 319 sequential number available in the SeND options, i.e., 15. When use 320 is made of the lifetime option, this field SHOULD be added to the 321 ICMPv6 option for RA messages. 323 8. Threat Analysis of Application Layer based lifetime 325 8.1. Location based tracking 327 Similar to the mechanism explained in RFC 4941 and [Ra-privacy], the 328 attacker might not have enough time to track the node. This is 329 because the IID is valid for only a short period of time and will 330 change when a new RA message is received. Since the IIDs are valid 331 for a short period of time, storing them using trap websites also 332 will not help the attackers because it will be changed after a while. 334 8.2. Obtaining confidential data 336 If for any reason one of the applications in use on this node exposed 337 the users' real IP address to an attacker, the attacker might not be 338 able to obtain other confidential information related to other user 339 applications on this node. This is because this IID is only used for 340 certain purposes and for certain applications. This IID is also valid 341 for only a short period of time, and so, the attacker might not have 342 enough time to obtain confidential information about this node.%h2 344 9. Security Considerations 346 As is explained in the Privacy Extension document, the same 347 approaches are used to maintain security, such as using Secure 348 Neighbor Discovery (SeND)(RFC 3971) or using a monitoring system 349 which would inform the administrator of the status of the network and 350 of any suspended activities in the network. 352 10. IANA Considerations 353 No IANA actions are needed for this document. 355 11. Conclusions 357 This document explained different mechanisms used for maintaining the 358 lifetime of an IID. It introduced an application layer based lifetime 359 as a solution for the lifetime used for temporary IIDs in order to 360 satisfy users needs and to not force them to cut their connections or 361 to not open a new connection with an application using a new IID that 362 could prove problematic for the application. 364 12. References 366 12.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to 369 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy 372 Extensions for Stateless Address Autoconfiguration in 373 IPv6", RFC 4941, September 2007. 375 [RFC3972] Aura, T., "Cryptographically Generated Addresses 376 (CGA)", RFC 3972, March 2005. 378 12.2. Informative References 380 [ssas] Rafiee, H., Meinel, C., "A Simple Secure Addressing 381 Scheme for IPv6 AutoConfiguration", Work In Progress, 382 http://tools.ietf.org/html/draft-rafiee-6man-ssas, July, 2013 384 [StableAddresses] Gont, F., "A method for 385 Generating Stable Privacy-Enhanced Addresses with 386 IPv6 Stateless Address Autoconfiguration (SLAAC)", 387 Work In Progress, 388 http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses, 389 August 2013 391 [ra-privacy] Rafiee, H., Meinel, C., "Router 392 Advertisement based privacy extension in IPv6 393 autoconfiguration", Work In 394 Progress,http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy, 395 July, 2013 397 [applicationiid] Rafiee, H., Meinel, C., "Privacy 398 and Security in IPv6 Networks: Challenges and 399 Possible Solution". The 6th International Conference 400 on Security of Information and Networks, ACM, 401 November 2013 403 Authors' Addresses 405 Hosnieh Rafiee 406 Hasso-Plattner-Institute 407 Prof.-Dr.-Helmert-Str. 2-3 408 Potsdam, Germany 409 Phone: +49 (0)331-5509-546 410 Email: ietf@rozanak.com 412 Erik Nordmark 413 Arista Networks 414 Santa Clara, CA 415 USA 416 Email: nordmark@acm.org 418 Dr. Christoph Meinel 419 (Professor) 420 Hasso-Plattner-Institute 421 Prof.-Dr.-Helmert-Str. 2-3 422 Potsdam, Germany 423 Email: meinel@hpi.uni-potsdam.de