idnits 2.17.1 draft-thaler-6lo-privacy-addrs-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 (February 16, 2015) is 3354 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: 'RFC7136' is defined on line 444, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-03 == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: Standards Track February 16, 2015 5 Expires: August 20, 2015 7 Enabling Security/Privacy Addressing On 6LoWPAN Technologies 8 draft-thaler-6lo-privacy-addrs-00 10 Abstract 12 It is commonly assumed today that 6LowPAN header compression is 13 incompatible (or at least inefficient) with the notion of using 14 addresses with sufficient entropy to mitigate various security and 15 privacy threats. This draft explores ways one might dispel that 16 notion, and discusses how security/privacy addressing might be used 17 on 6LoWPAN technologies without additional overhead in data packets. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 20, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Compression Details . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Use of IEEE-Identifier-Based Addresses . . . . . . . . . 4 57 3.2. Use of 16-Bit Short Addresses . . . . . . . . . . . . . . 5 58 3.3. Use of Non-IEEE-Identifier-Based Addresses . . . . . . . 6 59 3.3.1. Source Address Compression . . . . . . . . . . . . . 6 60 3.3.2. Destination Address Compression . . . . . . . . . . . 6 61 3.3.3. Context Identifier . . . . . . . . . . . . . . . . . 6 62 3.3.4. Context State . . . . . . . . . . . . . . . . . . . . 7 63 3.3.5. Context Distribution . . . . . . . . . . . . . . . . 7 64 3.3.6. Negotiation . . . . . . . . . . . . . . . . . . . . . 8 65 3.3.7. Discussion of Tradeoffs . . . . . . . . . . . . . . . 8 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 7.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Amount of Entropy Needed . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 RFC 6973 [RFC6973] discusses privacy considerations for Internet 78 protocols, and Section 5.2 in particular covers a number of privacy- 79 specific threats. In the context of IPv6 addresses, Section 3 of 80 [I-D.ietf-6man-ipv6-address-generation-privacy] provides further 81 elaboration on the applicability of the privacy threats. When 82 interface identifiers (IIDs) are generated without sufficient 83 entropy, devices and users become vulnerable to the various threats 84 discussed there, including correlation of activities over time, 85 location tracking, address scanning, and device-specific 86 vulnerability exploitation. 88 Interfaces identifiers formed from IEEE identifiers can have 89 insufficient entropy unless the IEEE identifier itself has sufficient 90 entropy, and enough bits of entropy are carried over into the IPv6 91 address to sufficiently mitigate the threats. Typically "enough" 92 bits of entropy means at least 46 bits (see Appendix for why); 93 ideally all 64 bits of the IID should be used, although historically 94 some bits have been excluded for reasons discussed in [RFC7421]. 96 Furthermore, IEEE-identifier-based IIDs are also insufficient to 97 prevent location tracking unless the IEEE identifier itself is 98 different at each network location. This observation suggests that 99 the privacy threats can be mitigated in either of two ways: either 100 use an IPv6 address generation mechanism that is not IEEE-identifier- 101 based, or else make sure the IEEE identifier contains at least 46 102 bits of entropy and is changed if a device moves to a different 103 network. For this reason, [I-D.ietf-6man-default-iids] recommends 104 using the address generation scheme in [RFC7217] by default, rather 105 than IEEE-identifier-based addresses. 107 Furthermore, to mitigate the threat of correlation of activities over 108 time, [RFC4941] specifies the notion of a "temporary" address to be 109 used for sessions that should not be linkable to a more permanent 110 identifier (such as a DNS name, user name, or stable hardware 111 address). Such temporary addresses are appropriate for connections 112 (typically locally-initiated outbound sessions) that an attacker 113 cannot link to a stable identifier such as a user name or DNS name. 114 Indeed, the default address selection rules [RFC6724] now prefer 115 temporary addresses by default for outgoing connections. When 116 temporary addresses are used, a new temporary address is periodically 117 (default is 1 day in [RFC4941]) generated, which limits the threat of 118 correlation of activies over time to that period. The address itself 119 though may still be usable for existing long-lived connections (but 120 not new connections) for some longer period (default is 1 week); this 121 allows for not breaking application sessions, especially those that 122 might be initiated shortly before a new temporary address is 123 generated. This fact means that multiple temporary addresses can 124 exist at the same time, one for new connections, and one or more 125 (often up to 6, per the default periods) old ones for long-lived 126 connections. This is in addition to any "stable" addresses that 127 might be used for connections that are linkable to more permanent 128 identifiers such as DNS names or user names. Whereas most threats 129 could be mitigated if the IEEE identifier contains sufficient entropy 130 and is different per-network, mitigating the threat of correlation of 131 activities over time typically cannot be done using an IEEE- 132 identifier-based-IID, since mitigating such a threat typically 133 involves the ability to use multiple IPv6 addresses simultaneously 134 whereas typically only one IEEE identifier can be used at a time. 136 Finally, allowing efficient use of addresses that are not IEEE- 137 identifier-based also has additional security benefits not specific 138 to privacy. For example, addresses such as Cryptographically 139 Generated Addresses (CGAs) [RFC3972] and Hash-Based Addresses (HBAs) 140 [RFC5535] can be used in security protocols such as Secure Neighbor 141 Discovery (SeND) [RFC6496], IPsec, etc. Such techniques rely on 142 having around 59 or more bits of entropy in the address to provide 143 sufficient cryptographic protection. 145 RFC 6775 [RFC6775] already allows for the use of non-IEEE-identifier- 146 based addresses, such as those provided by DHCPv6 [RFC3315]. There 147 has been some concern, however, that such approaches necessarily 148 interfere with efficient header compression for IPv6 (e.g., over IEEE 149 802.15.4-based networks [RFC6282]), as it is important to keep data 150 packets small on 6LoWPAN networks. 152 Another potential concern is that of efficiency, such as avoiding DAD 153 all together when IPv6 addresses are IEEE-identifier-based. 154 Appendix A of [RFC4429] provides an analysis of address collision 155 probability based on the number of bits of entropy. A simple web 156 search on "duplicate MAC addresses" will show that collisions do 157 happen with MAC addresses, and thus based on the analysis in 158 [RFC4429], using sufficient bits of entropy in non-IEEE-identifier- 159 based addresses can provide greater protection against collision than 160 using MAC addresses. 162 The remainder of this document explores how one might use addresses 163 with sufficient entropy on 6LoWPAN networks while avoiding extra 164 overhead. 166 2. Terminology 168 This document uses the terminology defined in Section 3 of [RFC6973], 169 including terms such as "(un)linkability" and "anonymity set". 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 3. Compression Details 177 The LOWPAN_IPHC encoding format specified in Section 3.1 of RFC 6282 178 [RFC6282] defines a method for deriving IIDs from the link-layer 179 source and/or destination addresses in the encapsulation header. 180 Unicast IPv6 addresses may be compressed to 64, 16, or 0 bits in the 181 encoded IPv6 header. 183 3.1. Use of IEEE-Identifier-Based Addresses 185 As noted earlier, some threats could be mitigated using per-network 186 "randomized" IEEE identifiers with 46 or more bits of entropy. A 187 number of such proposals can be found at 188 , and Section 10.8 of 189 [BTCorev4.1] specifies one for Bluetooth. Using IPv6 addresses 190 derived from such IEEE identifiers would be roughly equivalent to 191 those specified in [RFC7217]. 193 Such addresses would be encoded as usual using the LOWPAN_IPHC 194 encoding format. For example, if the source and destination 195 addresses are both on-link and derived from the IEEE identifier in 196 the encapsulating header: 198 o SAC (Source Address Compression) is set to 0 to indicate stateless 199 compression. 201 o SAM (Source Address Mode) is set to 11 to indicate the address is 202 fully elided and can be computed from the encapsulating header. 204 o DAC (Destination Address Compression) is set to 0 to indicate 205 stateless compression. 207 o DAM (Destination Address Mode) is set to 11 to indicate the 208 address is fully elided and can be computed from the encapsulating 209 header. 211 3.2. Use of 16-Bit Short Addresses 213 An IPv6 address formed (per Section 6 of [RFC4944]) from an 16-bit 214 identifier such as an IEEE 802.15.4 16-bit short address does not 215 provide sufficient entropy to fully mitigate address scanning, as the 216 size of the address scan search space depends on the entropy in the 217 IID, and only 15 bits are available for unicast addresses. An 218 adversary could also use statisical methods to determine the size of 219 the L2 address space and thereby make some inference regarding the 220 underlying technology being IEEE 802.15.4 on a given link. As such, 221 this address generation mechanism SHOULD NOT be used on networks 222 where privacy threats may be an issue, such as any networks that have 223 Internet connectivity. 225 It might be possible to construct IPv6 addresses from 16-bit short 226 addresses using an alternate mechanism that mitigates address scans, 227 if all nodes on a given L2 network have a shared secret (such as the 228 key needed to get on the layer-2 network) and generate the IID by 229 using a one-way 64-bit hash of the shared secret together with the 230 short address. The use of such a hash would result in the IIDs being 231 spread out among the full range of IID address space. 233 "Temporary" addresses could possibly be generated in the same way by 234 also including in the hash the Version Number from the Authoritative 235 Border Router Option (ABDO) if any. This would allow changing 236 temporary addresses whenever the Version Number is changed (even if 237 the set of prefix or context information is unchanged). Such a 238 scheme would likely require using the Context Identifier (CID) to 239 distinguish between non-temporary addresses, "current" temporary 240 addresses, and "past" temporary addresses based on a previous Version 241 Number. 243 Specifying further details of such a scheme is left for future 244 versions of this draft, if there is interest. 246 3.3. Use of Non-IEEE-Identifier-Based Addresses 248 Unicast addresses that are not IEEE-identifier based could be 249 compressed to 0 bits as follows, using stateful context-based 250 compression where the entire IPv6 address including the IID (as 251 opposed to only the IPv6 prefix) are covered by context information. 252 It is also worth pointing out that this same scheme would also allow 253 compressing DHCPv6-assigned addresses even in networks where privacy 254 is not a primary concern, thus potentially providing efficiency 255 benefits in addition to privacy and security ones. Furthermore, 256 unlike stateless compression, stateful context-based compression 257 could also allow compressing addresses of nodes outside the local 258 network (i.e., where the IEEE identifier in the encapsulating header 259 is that of a router rather than the peer, and the peer's address does 260 not have a prefix in the local network) and hence can provide greater 261 savings in such cases. 263 3.3.1. Source Address Compression 265 SAC (Source Address Compression) MUST be set to 1 to indicate 266 stateful context-based compression. 268 SAM (Source Address Mode) MUST be set to 11 to indicate that the 269 address is fully elided. 271 3.3.2. Destination Address Compression 273 DAC (Destination Address Compression) MUST be set to 1 to indicate 274 stateful context-based compression. 276 DAM (Destination Address Mode) MUST be set to 11 to indicate that the 277 address is fully elided. 279 3.3.3. Context Identifier 281 When non-IEEE-identifier-based addresses are used as described in 282 this document, each address MUST be associated with a separate 283 context. That is, the "prefix" associated with a context MUST be the 284 full 128 bits of the IPv6 address. 286 LOWPAN_IPHC supports up to 16 source address contexts and 16 287 destination address contexts, allowing for simultaneous use of up to 288 16 source addresses and 16 destination addresses that are not IEEE- 289 identifier-based. Context 0 is the default context if the CID 290 (Context Identifier Extension) octet is absent, and other values 291 require the CID to be present. As such, the address most commonly 292 used (typically either the stable non-temporary address, or the 293 currently preferred temporary address) could be assigned to context 0 294 so that the presence of the CID octet is minimized. 296 3.3.4. Context State 298 As specified in [RFC6775], context state is distributed by routers 299 and is shared across a LoWPAN. This means that the use of CIDs 300 described above would only support compression of 16 source and 301 destination addresses across the entire LoWPAN. However, Section 8 302 of [RFC6775] explicitly allows for such context dissemination to be 303 substituted by alternatives defined in other specifications. We now 304 describe such a substitute that would allow header compression with 305 up to 16 source addresses and 16 destination addresses *per node*. 307 First, a context entry is defined to be indexed by a { link-layer 308 address, CID } tuple, rather than just a CID. Second, each node is 309 responsible for generating and disseminating the CIDs for its own 310 IPv6 addresses. 312 Thus, each Neighbor Cache Entry (NCE) in a router conceptually 313 contains the CID of the neighbor's address, used when compressing 314 packets sent to it. 316 3.3.5. Context Distribution 318 To disseminate CID information from a host to a router, the Address 319 Registration Option (ARO) defined in Section 4.1 of [RFC6775] can be 320 extended to include the CID by using 5 of the 24 Reserved bits (one 321 for a flag to denote a CID is present, and 4 for the CID). For 322 distribution in a multihop network, the Duplicate Address Request 323 (DAR) and Duplicate Address Confirmation (DAC) messages can be 324 similarly extended to include the CID in currently Reserved bits. 326 To disseminate CID information from a router to a host, Section 4.2 327 of [RFC6775] defines the 6LoWPAN Context Option (6CO) for use in 328 Router Discovery. If a router sees that a host is sending packets 329 without compressing a source or destination address, the router could 330 send it an updated 6CO with a CID for that address as the context 331 prefix, to allow compression of subsequent packets. Since each non- 332 IEEE-identifier-based address requires its own context, the Context 333 Length field MUST be set to 128 in the 6CO containing such context 334 information. Note that the CID in a 6CO for another address within 335 the 6LoWPAN is still generated by the router (since it is specific to 336 the router's link-layer address as used by the host to which the 6CO 337 is sent); it is not the same value as the CID generated by the 338 destination node itself, which CID is used by its router when 339 forwarding a packet to it. Thus a router is responsible for updating 340 CIDs in packets it forwards, just as it updates the link-layer source 341 and destination addresses in the encapsulating header. 343 Specifying further details of such a scheme is left for future 344 versions of this draft, if there is interest. 346 3.3.6. Negotiation 348 To negotiate using the substitute mechanisms above, rather than the 349 default mechanisms specified in [RFC6775], the 6LoWPAN Capability 350 Indication Option (6CIO) could be used as allowed for in Section 3.4 351 of [RFC7400] by assigning one of the "6LoWPAN capability Bits" for 352 this purpose. 354 3.3.7. Discussion of Tradeoffs 356 This proposal decentralizes a portion of context generation and 357 distribution to include simple nodes. In many 6LoWPAN scenarios, as 358 much as possible is offloaded to router nodes precisely because end 359 nodes are so limited. Until context info is learned for a given 360 destination address, a node is not able to compress it. Compression 361 would kick in after the context info is known. After context info is 362 learned, the 4-bit CID must be stored for the destination address. 363 As such, using this scheme requires a slight amount of overhead in 364 the initial packet(s) but no additional overhead afterwards, and it 365 requires no additional memory overhead initially, but a slight amount 366 of additional memory overhead after context is learned. 368 In the rare case that a simple node needs to simultaneously 369 communicate with more than 16 other non-IEEE-identifier-based 370 destination addresses, at most 16 of them will be able to be 371 compressed, and the others will have additional packet overhead. 373 4. IANA Considerations 375 The approach described in Section 3.3 would require IANA to allocate 376 a bit in the "6LoWPAN capability Bits" subregistry for this purpose. 378 5. Security Considerations 380 This entire document is about security considerations and possible 381 mitigations. 383 6. Acknowledgements 385 Thanks to Fernando Gont, Christian Huitema, and Gabriel Montenegro 386 for discussion on the ideas described in this draft. 388 7. References 390 7.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 396 "Transmission of IPv6 Packets over IEEE 802.15.4 397 Networks", RFC 4944, September 2007. 399 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 400 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 401 September 2011. 403 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 404 "Neighbor Discovery Optimization for IPv6 over Low-Power 405 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 406 November 2012. 408 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 409 IPv6 over Low-Power Wireless Personal Area Networks 410 (6LoWPANs)", RFC 7400, November 2014. 412 7.2. Informative References 414 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 415 and M. Carney, "Dynamic Host Configuration Protocol for 416 IPv6 (DHCPv6)", RFC 3315, July 2003. 418 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 419 RFC 3972, March 2005. 421 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 422 for IPv6", RFC 4429, April 2006. 424 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 425 Extensions for Stateless Address Autoconfiguration in 426 IPv6", RFC 4941, September 2007. 428 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 429 2009. 431 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 432 Martinez, "Secure Proxy ND Support for SEcure Neighbor 433 Discovery (SEND)", RFC 6496, February 2012. 435 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 436 "Default Address Selection for Internet Protocol Version 6 437 (IPv6)", RFC 6724, September 2012. 439 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 440 Morris, J., Hansen, M., and R. Smith, "Privacy 441 Considerations for Internet Protocols", RFC 6973, July 442 2013. 444 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 445 Interface Identifiers", RFC 7136, February 2014. 447 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 448 Interface Identifiers with IPv6 Stateless Address 449 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 451 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 452 June 2014. 454 [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 455 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 456 in IPv6 Addressing", RFC 7421, January 2015. 458 [I-D.ietf-6man-ipv6-address-generation-privacy] 459 Cooper, A., Gont, F., and D. Thaler, "Privacy 460 Considerations for IPv6 Address Generation Mechanisms", 461 draft-ietf-6man-ipv6-address-generation-privacy-03 (work 462 in progress), January 2015. 464 [I-D.ietf-6man-default-iids] 465 Gont, F., Cooper, A., Thaler, D., and W. Will, 466 "Recommendation on Stable IPv6 Interface Identifiers", 467 draft-ietf-6man-default-iids-02 (work in progress), 468 January 2015. 470 [BTCorev4.1] 471 Bluetooth Special Interest Group, "Bluetooth Core 472 Specification Version 4.1", December 2013, 473 . 476 Appendix A. Amount of Entropy Needed 478 In terms of privacy threats discussed in 479 [I-D.ietf-6man-ipv6-address-generation-privacy], the one with the 480 need for the most entropy is address scans. To mitigate address 481 scans, one needs enough entropy to make the probability of a 482 successful address probe be negligible. Typically this is measured 483 in the length of time it would take to have a 50% probability of 484 getting at least one hit. Address scans often rely on sending a 485 packet such as a TCP SYN or ICMP Echo Request, and determining 486 whether the reply is an ICMP unreachable errors (if no host exists) 487 or TCP response or ICMP Echo Reply (if a host exists), or neither in 488 which case nothing is known for certain. 490 Many privacy-sensitive devices support a "stealth mode" as discussed 491 in Section 5 of [RFC7288] whereby they will not send a TCP RST or 492 ICMP Echo Reply. In such cases, and when the device does not listen 493 on a well-known TCP port known to the scanner, the effectiveness of 494 an address scan is limited by the ability to get ICMP unreachable 495 errors, since the attacker can only infer the presence of a host 496 based on the absense of an ICMP unreachable error. 498 Generation of ICMP unreachable errors is typically rate limited to 2 499 per second (the default in routers such as Cisco routers running IOS 500 12.0 or later). Such a rate results in taking about a year to 501 completely scan 26 bits of space. For a network with at most 2^16 502 devices on the same subnet, and the average lifetime of a device 503 being 16 (2^4) years or less, this results in a need for at least 46 504 bits of entropy (16+26+4) so that a address scan would need to be 505 sustained for longer than the lifetime of devices to have a 50% 506 chance of getting a hit. 508 The actual math is as follows. Let 2^N be the number of devices on 509 the subnet. Let 2^M be the size of the space to scan (i.e., M bits 510 of entropy). Let S be the number of scan attempts. The formula is: 511 P(at least one success) = 1 - (1 - 2^N/2^M)^S = 1/2. Assuming 2^M >> 512 S, this simplifies to: S * 2^N/2^M = 1/2, giving S = 2^(M-N) / 2, or 513 M = N + log_2(2S). 515 Although 46 bits of entropy may be enough to provide privacy in such 516 cases, 59 or more bits of entropy are needed if addresses are used to 517 provide security against attacks such as spoofing, as CGAs [RFC3972] 518 and HBAs [RFC5535] do, since attacks are not limited by ICMP rate 519 limiting but by the processing power of the attacker. See those RFCs 520 for more discussion. 522 If, on the other hand, the devices being scanned for do not implement 523 a "stealth mode", but respond with TCP RST or ICMP Echo Reply 524 packets, then the address scan is not limited by the ICMP unreachable 525 rate limit in routers, since the attacker can determine the presence 526 of a host without them. In such cases, more bits of entropy would be 527 needed to provide the same level of protection. 529 Author's Address 531 Dave Thaler 532 Microsoft 533 One Microsoft Way 534 Redmond, WA 98052 535 USA 537 Email: dthaler@microsoft.com