idnits 2.17.1 draft-ietf-6lo-privacy-considerations-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 307, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-08 == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-02 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-03 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-02 == Outdated reference: A later version (-03) exists of draft-huitema-6man-random-addresses-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational October 18, 2015 5 Expires: April 20, 2016 7 Privacy Considerations for IPv6 over Networks of Resource-Constrained 8 Nodes 9 draft-ietf-6lo-privacy-considerations-00 11 Abstract 13 This document discusses how a number of privacy threats apply to 14 technologies designed for IPv6 over networks of resource-constrained 15 nodes, and provides advice to protocol designers on how to address 16 such threats in IPv6-over-foo adaptation layer specifcations. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 20, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Amount of Entropy Needed . . . . . . . . . . . . . . . . . . 3 54 3. Potential Approaches . . . . . . . . . . . . . . . . . . . . 4 55 3.1. IEEE-Identifier-Based Addresses . . . . . . . . . . . . . 5 56 3.2. Short Addresses . . . . . . . . . . . . . . . . . . . . . 5 57 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 7.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 RFC 6973 [RFC6973] discusses privacy considerations for Internet 68 protocols, and Section 5.2 in particular covers a number of privacy- 69 specific threats. In the context of IPv6 addresses, Section 3 of 70 [I-D.ietf-6man-ipv6-address-generation-privacy] provides further 71 elaboration on the applicability of the privacy threats. 73 When interface identifiers (IIDs) are generated without sufficient 74 entropy compared to the link lifetime, devices and users can become 75 vulnerable to the various threats discussed there, including: 77 o Correlation of activities over time, if the same identifier is 78 used for Internet traffic over period of time 80 o Location tracking, if the same interface identifier is used with 81 different prefixes as a device moves between different networks 83 o Device-specific vulnerability exploitation, if the identifier 84 helps identify a vendor or version or protocol and hence suggests 85 what types of attacks to try 87 o Address scanning, which enables all of the above attacks by off- 88 link attackers. 90 Typically "enough" bits of entropy means at least 46 bits (see 91 Section 2 for why); ideally all 64 bits of the IID should be used, 92 although historically some bits have been excluded for reasons 93 discussed in [RFC7421]. 95 For these reasons, [I-D.ietf-6man-default-iids] recommends using an 96 address generation scheme in [RFC7217], rather than addresses 97 generated from a fixed IEEE identifier. 99 Furthermore, to mitigate the threat of correlation of activities over 100 time on long-lived links, [RFC4941] specifies the notion of a 101 "temporary" address to be used for transport sessions (typically 102 locally-initiated outbound traffic to the Internet) that should not 103 be linkable to a more permanent identifier such as a DNS name, user 104 name, or stable hardware address. Indeed, the default address 105 selection rules [RFC6724] now prefer temporary addresses by default 106 for outgoing connections. If a device needs to simultaneously 107 support unlinkable traffic as well as traffic that is linkable to 108 such a stable identifier, this necessitates supporting simultaneous 109 use of multiple addresses per device. 111 2. Amount of Entropy Needed 113 In terms of privacy threats discussed in 114 [I-D.ietf-6man-ipv6-address-generation-privacy], the one with the 115 need for the most entropy is address scans. To mitigate address 116 scans, one needs enough entropy to make the probability of a 117 successful address probe be negligible. Typically this is measured 118 in the length of time it would take to have a 50% probability of 119 getting at least one hit. Address scans often rely on sending a 120 packet such as a TCP SYN or ICMP Echo Request, and determining 121 whether the reply is an ICMP unreachable error (if no host exists) or 122 a TCP response or ICMP Echo Reply (if a host exists), or neither in 123 which case nothing is known for certain. 125 Many privacy-sensitive devices support a "stealth mode" as discussed 126 in Section 5 of [RFC7288] whereby they will not send a TCP RST or 127 ICMP Echo Reply. In such cases, and when the device does not listen 128 on a well-known TCP port known to the scanner, the effectiveness of 129 an address scan is limited by the ability to get ICMP unreachable 130 errors, since the attacker can only infer the presence of a host 131 based on the absense of an ICMP unreachable error. 133 Generation of ICMP unreachable errors is typically rate limited to 2 134 per second (the default in routers such as Cisco routers running IOS 135 12.0 or later). Such a rate results in taking about a year to 136 completely scan 26 bits of space. 138 The actual math is as follows. Let 2^N be the number of devices on 139 the subnet. Let 2^M be the size of the space to scan (i.e., M bits 140 of entropy). Let S be the number of scan attempts. The formula for 141 a 50% chance of getting at least one hit in S attempts is: P(at least 142 one success) = 1 - (1 - 2^N/2^M)^S = 1/2. Assuming 2^M >> S, this 143 simplifies to: S * 2^N/2^M = 1/2, giving S = 2^(M-N-1), or M = N + 1 144 + log_2(S). Using a scan rate of 2 per second, this results in the 145 following rule of thumb: 147 Bits of entropy needed = log_2(# devices per link) + log_2(seconds 148 of link lifetime) + 2 150 For example, for a network with at most 2^16 devices on the same 151 long-lived link, and the average lifetime of a device being 8 years 152 (2^28 seconds) or less, this results in a need for at least 46 bits 153 of entropy (16+28+2) so that an address scan would need to be 154 sustained for longer than the lifetime of devices to have a 50% 155 chance of getting a hit. 157 Although 46 bits of entropy may be enough to provide privacy in such 158 cases, 59 or more bits of entropy would be needed if addresses are 159 used to provide security against attacks such as spoofing, as CGAs 160 [RFC3972] and HBAs [RFC5535] do, since attacks are not limited by 161 ICMP rate limiting but by the processing power of the attacker. See 162 those RFCs for more discussion. 164 If, on the other hand, the devices being scanned for do not implement 165 a "stealth mode", but respond with TCP RST or ICMP Echo Reply 166 packets, then the address scan is not limited by the ICMP unreachable 167 rate limit in routers, since the attacker can determine the presence 168 of a host without them. In such cases, more bits of entropy would be 169 needed to provide the same level of protection. 171 3. Potential Approaches 173 The table below shows the number of bits of entropy currently 174 available in various technologies: 176 +---------------+--------------------------+--------------------+ 177 | Technology | Reference | Bits of Entropy | 178 +---------------+--------------------------+--------------------+ 179 | 802.15.4 | [RFC4944] | 16+ or any EUI-64 | 180 | Bluetooth LE | [I-D.ietf-6lo-btle] | 48 | 181 | DECT ULE | [I-D.ietf-6lo-dect-ule] | 40 or any EUI-48 | 182 | MS/TP | [I-D.ietf-6lo-6lobac] | 8 or 64 | 183 | ITU-T G.9959 | [RFC7428] | 8 | 184 | NFC | [I-D.ietf-6lo-nfc] | 6 or ??? | 185 +---------------+--------------------------+--------------------+ 187 Such technologies generally support either IEEE identifiers or so 188 called "Short Addresses", or both, as link layer addresses. We 189 discuss each in turn. 191 3.1. IEEE-Identifier-Based Addresses 193 Some technologies allow the use of IEEE EUI-48 or EUI-64 identifiers, 194 or allow using an arbitrary 64-bit identifier. Using such an 195 identifier to construct IPv6 addresses makes it easy to use the 196 normal LOWPAN_IPHC encoding with stateless compression, allowing such 197 IPv6 addresses to be fully elided in common cases. 199 Interfaces identifiers formed from IEEE identifiers can have 200 insufficient entropy unless the IEEE identifier itself has sufficient 201 entropy, and enough bits of entropy are carried over into the IPv6 202 address to sufficiently mitigate the threats. Privacy threats other 203 than "Correlation over time" can be mitigated using per-network 204 randomized IEEE identifiers with 46 or more bits of entropy. A 205 number of such proposals can be found at 206 , and Section 10.8 of 207 [BTCorev4.1] specifies one for Bluetooth. Using IPv6 addresses 208 derived from such IEEE identifiers would be roughly equivalent to 209 those specified in [RFC7217]. 211 Correlation over time can be mitigated if the IEEE identifier itself 212 changes often enough, such as each time the link is established, if 213 the link lifetime is short. For further discussion, see 214 [I-D.huitema-6man-random-addresses]. 216 Another potential concern is that of efficiency, such as avoiding DAD 217 all together when IPv6 addresses are IEEE-identifier-based. 218 Appendix A of [RFC4429] provides an analysis of address collision 219 probability based on the number of bits of entropy. A simple web 220 search on "duplicate MAC addresses" will show that collisions do 221 happen with MAC addresses, and thus based on the analysis in 222 [RFC4429], using sufficient bits of entropy in random addresses can 223 provide greater protection against collision than using MAC 224 addresses. 226 3.2. Short Addresses 228 An IPv6 interface identifier formed from a "Short Address" and a set 229 of well-known constant bits (such as padding with 0's) lacks 230 sufficient entropy to mitigate address scanning unless the link 231 lifetime is extremely short. Furthermore, an adversary could also 232 use statisical methods to determine the size of the L2 address space 233 and thereby make some inference regarding the underlying technology 234 on a given link, and target further attacks accordingly. 236 When Short Addresses are desired on links that are not guaranteed to 237 have a short enough lifetime, the mechanism for constructing an IPv6 238 interface identifier from a Short Address could be designed to 239 sufficiently mitigate the problem. For example, if all nodes on a 240 given L2 network have a shared secret (such as the key needed to get 241 on the layer-2 network), the 64-bit IID might be generated using a 242 one-way hash that includes (at least) the shared secret together with 243 the Short Address. The use of such a hash would result in the IIDs 244 being spread out among the full range of IID address space, thus 245 mitigating address scans, while still allowing full stateless 246 compression/elision. 248 For long-lived links, "temporary" addresses might even be generated 249 in the same way by (for example) also including in the hash the 250 Version Number from the Authoritative Border Router Option (ABDO) if 251 any. This would allow changing temporary addresses whenever the 252 Version Number is changed, even if the set of prefix or context 253 information is unchanged. 255 In summary, any specification using Short Addresses should carefully 256 construct an IID generation mechanism so as to provide sufficient 257 entropy compared to the link lifetime. 259 4. Recommendations 261 The following are recommended for adaptation layer specifications: 263 o Security (privacy) sections should say how address scans are 264 mitigated. An address scan might be mitigated by having a link 265 always be short-lived, or might be mitigated by having a large 266 number of bits of entropy, or some combination. Thus, a 267 specification should explain what the maximum lifetime of a link 268 is in practice, and show how the number of bits of entropy is 269 sufficient given that lifetime. 271 o Technologies must define a way to include sufficient bits of 272 entropy in the IPv6 interface identifier, based on the maximum 273 link lifetime. Specifying that a random EUI-48 or EUI-64 can be 274 used is one easy way to do so, for technologies that support such 275 identifiers. 277 o Specifications should not simply construct an IPv6 interface 278 identifier by padding a short address with a set of other well- 279 known constant bits, unless the link lifetime is guaranteed to be 280 extremely short. 282 o Specifications should make sure that an IPv6 address can change 283 over long periods of time. For example, the interface identifier 284 might change each time a device connects to the network (if 285 connections are short), or might change each day (if connections 286 can be long). This is necessary to mitigate correlation over 287 time. 289 o If a device can roam between networks, and more than a few bits of 290 entropy exist in the IPv6 interface identifier, then make sure 291 that the interface identifier can vary per network as the device 292 roams. This is necessary to mitigate location tracking. 294 5. IANA Considerations 296 This document has no actions for IANA. 298 6. Security Considerations 300 This entire document is about security considerations and how to 301 specify possible mitigations. 303 7. References 305 7.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 7.2. Informative References 314 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 315 RFC 3972, DOI 10.17487/RFC3972, March 2005, 316 . 318 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 319 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 320 . 322 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 323 Extensions for Stateless Address Autoconfiguration in 324 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 325 . 327 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 328 "Transmission of IPv6 Packets over IEEE 802.15.4 329 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 330 . 332 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 333 DOI 10.17487/RFC5535, June 2009, 334 . 336 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 337 "Default Address Selection for Internet Protocol Version 6 338 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 339 . 341 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 342 Morris, J., Hansen, M., and R. Smith, "Privacy 343 Considerations for Internet Protocols", RFC 6973, 344 DOI 10.17487/RFC6973, July 2013, 345 . 347 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 348 Interface Identifiers with IPv6 Stateless Address 349 Autoconfiguration (SLAAC)", RFC 7217, 350 DOI 10.17487/RFC7217, April 2014, 351 . 353 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 354 DOI 10.17487/RFC7288, June 2014, 355 . 357 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 358 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 359 Boundary in IPv6 Addressing", RFC 7421, 360 DOI 10.17487/RFC7421, January 2015, 361 . 363 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 364 over ITU-T G.9959 Networks", RFC 7428, 365 DOI 10.17487/RFC7428, February 2015, 366 . 368 [I-D.ietf-6man-ipv6-address-generation-privacy] 369 Cooper, A., Gont, F., and D. Thaler, "Privacy 370 Considerations for IPv6 Address Generation Mechanisms", 371 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 372 in progress), September 2015. 374 [I-D.ietf-6man-default-iids] 375 Gont, F., Cooper, A., Thaler, D., and S. LIU, 376 "Recommendation on Stable IPv6 Interface Identifiers", 377 draft-ietf-6man-default-iids-08 (work in progress), 378 October 2015. 380 [I-D.ietf-6lo-6lobac] 381 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 382 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 383 6lo-6lobac-02 (work in progress), July 2015. 385 [I-D.ietf-6lo-btle] 386 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 387 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 388 Energy", draft-ietf-6lo-btle-17 (work in progress), August 389 2015. 391 [I-D.ietf-6lo-dect-ule] 392 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 393 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 394 Energy", draft-ietf-6lo-dect-ule-03 (work in progress), 395 September 2015. 397 [I-D.ietf-6lo-nfc] 398 Hong, Y. and J. Youn, "Transmission of IPv6 Packets over 399 Near Field Communication", draft-ietf-6lo-nfc-02 (work in 400 progress), October 2015. 402 [I-D.huitema-6man-random-addresses] 403 Huitema, C., "Implications of Randomized Link Layers 404 Addresses for IPv6 Address Assignment", draft-huitema- 405 6man-random-addresses-02 (work in progress), August 2015. 407 [BTCorev4.1] 408 Bluetooth Special Interest Group, "Bluetooth Core 409 Specification Version 4.1", December 2013, 410 . 413 Author's Address 415 Dave Thaler 416 Microsoft 417 One Microsoft Way 418 Redmond, WA 98052 419 USA 421 Email: dthaler@microsoft.com