idnits 2.17.1 draft-gont-6man-managing-privacy-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group F. Gont 3 (6man) UTN/FRH 4 Internet-Draft R. Broersma 5 Updates: 4861 (if approved) DREN 6 Intended status: Standards Track March 12, 2011 7 Expires: September 13, 2011 9 Managing the Use of Privacy Extensions for Stateless Address 10 Autoconfiguration in IPv6 11 draft-gont-6man-managing-privacy-extensions-01 13 Abstract 15 This document describes an operational problem that arises due to the 16 impossibility of managing the use of "Privacy Extensions" for IPv6 17 Stateless Address Autoconfiguration (SLAAC) in network scenarios that 18 employ SLAAC. Additionally, this document specifies new flag in the 19 Prefix Information option of Router Advertisement messages, such that 20 routers can advertise, for each network prefix to be used for SLAAC, 21 whether the aforementioned "Privacy Extensions" should be used. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, and it may not be 28 published except as an Internet-Draft. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 13, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Updating the Prefix Information option . . . . . . . . . . . . 4 61 2.1. Router specification . . . . . . . . . . . . . . . . . . . 5 62 2.2. Host specification . . . . . . . . . . . . . . . . . . . . 5 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Appendix A. Possible alternatives . . . . . . . . . . . . . . . . 11 70 A.1. Specifying a 'hardware-addresses' bit . . . . . . . . . . 11 71 A.2. Specifying a 'privacy-addresses' bit . . . . . . . . . . . 12 72 Appendix B. Changes from previous versions of the draft (to 73 be removed by the RFC Editor before publication 74 of this document as a RFC . . . . . . . . . . . . . . 14 75 B.1. Changes from 76 draft-gont-6man-managing-privacy-extensions-00 . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 [RFC4862] specifies the Stateless Address Autoconfiguration (SLAAC) 82 for IPv6, which typically results in hosts configuring one or more 83 addresses composed of a network prefix advertised by a local router, 84 and an Interface Identifier (IID) derived from a hardware address 85 (such as an Ethernet MAC address). 87 Since e.g. Ethernet MAC addresses are typically globally unique, 88 IPv6 addresses generated as specified in [RFC4862] could possibly be 89 levareged to track and correlate the activity of a node, thus 90 negatively affecting the privacy of users. 92 The "Privacy Extensions for Stateless Address Autoconfiguration in 93 IPv6" [RFC4941] were introduced difficult the task of eavesdroppers 94 and other information collectors to correlate the activities of a 95 node, and basically result in random Interface Identifiers which may 96 be more difficult to leverage than their hardware-derived 97 counterpart. These "Privacy Extensions" have been implemented in a 98 variety of systems, some of which (notably that in Microsoft Windows 99 Vista and Microsoft Windows 7) enable them by default. 101 The imposibility of managing the use of "Privacy Extensions" poses 102 poses a problem when a site has a specific policy for the generation 103 of IPv6 Interface Identifiers. For example, if hosts that enable 104 "Privacy Extensions" (by default) need to be deployed on sites that 105 require the use of hardware-derived Interface Identifiers, an 106 administrator may need to manually disable the use of "Privacy 107 Extensions" in each of the attached nodes. This not only may result 108 in a lot of work on the side of the administrator, but may also be 109 difficult to implement (particularly when considering mobile 110 computers such as laptops) [Broersma]. On the other hand, in some 111 environments (e.g., a typical home network) the use of "Privacy 112 Extensions" might be desirable. However, the imposibility to 113 automatically enable "Privacy Extensions" may preclude their use 114 (unless they are manually enabled by the administrator). 116 This document specifies a new flag in the Prefix Information option 117 of Router Advertisement messages, such that routers can advertise, 118 for each network prefix to be used for SLAAC, whether the 119 aforementioned "Privacy Extensions" should be used. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Updating the Prefix Information option 127 The syntax of the Prefix Information option is updated as follows: 129 0 1 2 3 130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Type | Length | Prefix Length |L|A|R|SAG|Rsvd1| 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Valid Lifetime | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Preferred Lifetime | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Reserved2 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | | 141 + + 142 | | 143 + Prefix + 144 | | 145 + + 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 An additional field, the two-bit "SAG" (Stateless Address Generation) 150 field, is ispecified for the Prefix Information option. The 151 semantics of each of the possible values are: 153 00: 154 No specific advice is provided for the generation of addresses for 155 this prefix. 157 01: 158 When generating addresses for this prefix, the resulting addresses 159 SHOULD be based on the underlying hardware address of the 160 interface (e.g., the Ethernet MAC address). 162 10: 163 When generating addresses for this prefix, Privacy Extensions for 164 SLAAC SHOULD be employed. 166 11: 167 Unused (reserved for future use). 169 The "R" bit was specified by [RFC3775]. The Rsvd1 field 170 corresponds to the remaining reserved bits, and thus MUST be set 171 to zero by the sender of this option, and ignored by the receiver. 173 Since the "SAG" bits correspond to a previously "reserved" field, 174 implementations that predate this specification should be setting the 175 SAG field to "00" when sending the option, and ignoring the SAG bits 176 upon receipt. 178 2.1. Router specification 180 Routers that have no particular preference on the address generation 181 policy MUST set the SAG bits to "00". Otherwise, they SHOULD set the 182 SAG bits to "01" or "10" according to the preferred address 183 generation policy. The special value "11" is reserved for future 184 extensions, and MUST NOT be set by routers implementing this 185 specification. 187 2.2. Host specification 189 When generating addresses for the prefix contained in the "Prefix 190 Information Option", hosts SHOULD apply the policy specified by the 191 "SAG" field. If no specific advice is provided (i.e., the SAG field 192 is set to "00"), hosts are free with respect to which policy to 193 employ when generating addresses for this prefix. Hosts that 194 implement this specification MUST interpret the special value "11" in 195 the same way as "00" (i.e., no specific advice is provided for 196 address generation). 198 3. Security Considerations 200 An attacker could exploit the mechanism specified in this document to 201 cause hosts in a given subnet to disable Privacy Extensions, thus 202 causing their Interface Identifiers to be derived from hardware 203 addresses, instead. Thus, the privacy of the victim hosts that would 204 have enabled the Privacy Extensions could possibly be reduced. 206 However, it should be noted that this attack would require from an 207 attacker the same effort as all the other Neighbor Discovery attack 208 vectors that are based on crafted Router Advertisement messages, most 209 of which are far more interesting for an attacker than this possible 210 attack vector. 212 Among the possible options for mitigating this and other attack 213 vectors based on crafted Router Advertisement messages is the 214 deployment of the so-called "Router Advertisement guard" mechanism 215 [I-D.ietf-v6ops-ra-guard]. 217 SEND (SEcure Neighbor Discovery) [RFC3971] could be pontentially 218 deployed to mitigate most Neighbor Discovery attacks. However, a 219 number of issues (such as the requirement for Public Key 220 Infrastructure) preclude the deployment of SEND in most general 221 network scenarions. [CPNI-IPv6] 223 Finally, we note that while the value and effectiveness of privacy 224 addreses have been questioned in a number of studies 225 [I-D.dupont-ipv6-rfc3041harmful] [Escudero] [CPNI-IPv6], this 226 document does not take a stance about their value and effectiveness: 227 it limits itself to discussing the operational problem that arises 228 due to the impossibility of managing the use of "Privacy Extensions", 229 and updating the "Prefix Information" option such that "Privacy 230 Extensions" can be more easily managed when IPv6 Stateless Address 231 Autoconfiguration (SLAAC) is employed. 233 4. IANA Considerations 235 There are no IANA registries within this document. The RFC-Editor 236 can remove this section before publication of this document as an 237 RFC. 239 5. Acknowledgements 241 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 242 their continued support. 244 6. References 246 6.1. Normative References 248 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 249 (IPv6) Specification", RFC 2460, December 1998. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 255 in IPv6", RFC 3775, June 2004. 257 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 258 Neighbor Discovery (SEND)", RFC 3971, March 2005. 260 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 261 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 262 September 2007. 264 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 265 Address Autoconfiguration", RFC 4862, September 2007. 267 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 268 Extensions for Stateless Address Autoconfiguration in 269 IPv6", RFC 4941, September 2007. 271 6.2. Informative References 273 [I-D.ietf-v6ops-ra-guard] 274 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 275 Mohacsi, "IPv6 Router Advertisement Guard", 276 draft-ietf-v6ops-ra-guard-08 (work in progress), 277 September 2010. 279 [I-D.dupont-ipv6-rfc3041harmful] 280 Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", 281 draft-dupont-ipv6-rfc3041harmful-05 (work in progress), 282 June 2004. 284 [Broersma] 285 Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- 286 enabled environment", Australian IPv6 Summit 2010, 287 Melbourne, VIC Australia, October 2010, 288 . 290 [Escudero] 291 Escudero, A., "PRIVACY EXTENSIONS FOR STATELESS ADDRESS 292 AUTOCONFIGURATION IN IPV6 - "REQUIREMENTS FOR 293 UNOBSERVABILITY", RVK02, Stockholm, 2002, 294 . 296 [CPNI-IPv6] 297 Gont, F., "Security Assessment of the Internet Protocol 298 version 6 (IPv6)", UK Centre for the Protection of 299 National Infrastructure, (to be published). 301 Appendix A. Possible alternatives 303 The following subsections describe possible alternatives (less 304 optimal from the point of vew of the authors of this document). The 305 main drawback is that if a single bit is specifed, then it's 306 impossible to disambiguate between the case in which this 307 specification is not supported (and thus the bit was "Reserved and 308 set to "0"), and the case whether this specification is supported and 309 the correspoding bit is meant to give specific advice on the desired 310 address generation policy. 312 A.1. Specifying a 'hardware-addresses' bit 314 The syntax of the Prefix Information option is updated as follows: 316 0 1 2 3 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Length | Prefix Length |L|A|R|H| Rsvd1 | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Valid Lifetime | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Preferred Lifetime | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Reserved2 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 + + 329 | | 330 + Prefix + 331 | | 332 + + 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 An additional bit, "H" ("Hardware-derived addresses"), is specified 337 for the Prefix Information option. When set, this bit indicates that 338 hardware-derived addresses SHOULD be used when configuring IPv6 339 addresses as a result of Stateless Address Autoconfiguration. When 340 not set, this bit indicates that Privacy Extensions SHOULD be enabled 341 when configuring IPv6 addresses as a result of Stateless Address 342 Autoconfiguration 343 The "R" bit was specified by [RFC3775]. The Rsvd1 field 344 corresponds to the remaining reserved bits, and thus MUST be set 345 to zero by the sender of this option, and ignored by the receiver. 347 Since the "H" bit was a previously reserved field, implementations 348 that predate this specification should be setting this bit to zero 349 when sending the option, and ignoring this bit upon receipt. 351 The following table illustrates the result of SLAAC depending on 352 whether this specification is supported by the router and/or the host 353 participanting in SLAAC. 355 +---------------+--------------------------+------------------------+ 356 | Router / Host | Supported | Not Supported | 357 +---------------+--------------------------+------------------------+ 358 | Supported | As indicated by the "H" | As in current | 359 | | bit | scenarios | 360 +---------------+--------------------------+------------------------+ 361 | Not Supported | Privacy Addresses | As in current | 362 | | | scenarios | 363 +---------------+--------------------------+------------------------+ 365 Table 1: Possible results of SLAAC scenarios 367 A.2. Specifying a 'privacy-addresses' bit 369 If rather than specifying an "H" bit, our I-D were to specify a "P" 370 ("Privacy addresses") bit, the resulting possible scenarios would 371 change as follows: 373 The following table illustrates the result of SLAAC depending on 374 whether this specification is supported at the router and/or host 375 participanting in SLAAC. 377 +---------------+---------------------------+-----------------------+ 378 | Router / Host | Supported | Not Supported | 379 +---------------+---------------------------+-----------------------+ 380 | Supported | As indicated by the "P" | As in current | 381 | | bit | scenarios | 382 +---------------+---------------------------+-----------------------+ 383 | Not Supported | Hardware-derived | As in current | 384 | | addresses | scenarios | 385 +---------------+---------------------------+-----------------------+ 387 Table 2: Alt. Possible results of SLAAC scenarios 389 As you may see, in this case only one scenario changes: when this 390 spec is not supported by the router, but *is* supported by the host, 391 hardware addresses are used. This would mean that if e.g. MS were 392 to implement this spec before e.g. Cisco, Privacy Addresses would be 393 disabled. 395 Clearly, there's a tradeoff here. 397 Appendix B. Changes from previous versions of the draft (to be removed 398 by the RFC Editor before publication of this document as a 399 RFC 401 B.1. Changes from draft-gont-6man-managing-privacy-extensions-00 403 o Rather that specifying a single bit in the Prefix Information 404 Options, a two-bit SAG field is specified -- with the previous 405 options being moved to an appendix (Appendix A). 407 o Fixes writeos in the tables contained in Appendix A.1 and 408 Appendix A.2. 410 Authors' Addresses 412 Fernando Gont 413 Universidad Tecnologica Nacional / Facultad Regional Haedo 414 Evaristo Carriego 2644 415 Haedo, Provincia de Buenos Aires 1706 416 Argentina 418 Phone: +54 11 4650 8472 419 Email: fernando@gont.com.ar 421 Ron Broersma 422 Defense Research and Engineering Network 424 Email: ron@spawar.navy.mil