idnits 2.17.1 draft-ietf-opsec-ipv6-host-scanning-05.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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC5157, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2015) is 3383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-01 == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-03 == Outdated reference: A later version (-02) exists of draft-ietf-dhc-stable-privacy-addresses-00 == Outdated reference: A later version (-27) exists of draft-ietf-opsec-v6-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft Huawei Technologies 4 Obsoletes: 5157 (if approved) T. Chown 5 Intended status: Informational University of Southampton 6 Expires: July 23, 2015 January 19, 2015 8 Network Reconnaissance in IPv6 Networks 9 draft-ietf-opsec-ipv6-host-scanning-05 11 Abstract 13 IPv6 offers a much larger address space than that of its IPv4 14 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate 15 approximately 1.844 * 10^19 hosts, thus resulting in a much lower 16 host density (#hosts/#addresses) than is typical in IPv4 networks, 17 where a site typically has 65,000 or less unique addresses. As a 18 result, it is widely assumed that it would take a tremendous effort 19 to perform address scanning attacks against IPv6 networks, and 20 therefore brute-force IPv6 address scanning attacks have been 21 considered unfeasible. This document updates RFC 5157, which first 22 discussed this assumption, by providing further analysis on how 23 traditional address scanning techniques apply to IPv6 networks, and 24 exploring some additional techniques that can be employed for IPv6 25 network reconnaissance. In doing so, this document formally 26 obsoletes RFC 5157. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 23, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements for the Applicability of Network Reconnaissance 64 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 67 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 68 3.1.2. Dynamic Host Configuration Protocol version 6 69 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10 70 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10 71 3.1.4. IPv6 Addresses Corresponding to Transition/Co- 72 existence Technologies . . . . . . . . . . . . . . . 12 73 3.1.5. IPv6 Address Assignment in Real-world Network 74 Scenarios . . . . . . . . . . . . . . . . . . . . . . 13 75 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15 76 3.2.1. Reducing the subnet ID search space . . . . . . . . . 16 77 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16 78 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 17 79 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 17 80 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 18 81 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 82 4. Leveraging the Domain Name System (DNS) for Network 83 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 84 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 85 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 20 86 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 20 87 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 88 5. Leveraging Local Name Resolution and Service Discovery 89 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21 91 7. Application Participation . . . . . . . . . . . . . . . . . . 21 92 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 93 9. Inspection of System Configuration and Log Files . . . . . . 22 94 10. Gleaning Information from Routing Protocols . . . . . . . . . 23 95 11. Gleaning Information from IP Flow Information Export (IPFIX) 23 96 12. Obtaining Network Information with traceroute6 . . . . . . . 23 97 13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 100 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 101 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 17.1. Normative References . . . . . . . . . . . . . . . . . . 24 103 17.2. Informative References . . . . . . . . . . . . . . . . . 25 104 Appendix A. Implementation of a full-fledged IPv6 address- 105 scanning tool . . . . . . . . . . . . . . . . . . . 28 106 A.1. Host-probing considerations . . . . . . . . . . . . . . . 28 107 A.2. Implementation of an IPv6 local address-scanning tool . . 30 108 A.3. Implementation of a IPv6 remote address-scanning tool . . 31 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 The main driver for IPv6 [RFC2460] deployment is its larger address 114 space [CPNI-IPv6]. This larger address space not only allows for an 115 increased number of connected devices, but also introduces a number 116 of subtle changes in several aspects of the resulting networks. One 117 of these changes is the reduced host density (the number of hosts 118 divided by the number of addresses) of typical IPv6 subnetworks: with 119 default IPv6 subnets of /64, each subnet comprises more than 1.844 * 120 10^19 available addresses; however, the actual number of nodes in 121 each subnet is likely to remain similar to that of IPv4 subnetworks 122 (typically a few hundred nodes per subnet). [RFC5157] describes how 123 this significantly lower IPv6 host-density is likely to make classic 124 network address scans less feasible, since even by applying various 125 heuristics, the address space to be scanned remains very large. RFC 126 5157 goes on to describe some alternative methods for attackers to 127 glean active IPv6 addresses, and provides some guidance for 128 administrators and implementors, e.g. not using sequential addresses 129 with DHCPv6. 131 With the benefit of five years of additional IPv6 deployment 132 experience, this document formally updates and obsoletes RFC 5157. 133 It emphasises that while scanning attacks are less feasible, they 134 may, with appropriate heuristics, remain possible. At the time that 135 RFC 5157 was written, observed scans were typically across ports on 136 the addresses of discovered servers; since then, evidence that some 137 classic address scanning is occurring is being witnessed. This text 138 thus updates the analysis on the feasibility of "traditional" 139 address-scanning attacks in IPv6 networks, and it explores a number 140 of additional techniques that can be employed for IPv6 network 141 reconnaissance. Practical examples and guidance are also included in 142 the Appendices. 144 On one hand, raising awareness about IPv6 network reconnaissance 145 techniques may allow (in some cases) network and security 146 administrators to prevent or detect such attempts. On the other 147 hand, network reconnaissance is essential for the so-called 148 "penetration tests" typically performed to assess the security of 149 production networks. As a result, we believe the benefits of a 150 thorough discussion of IPv6 network reconnaissance are two-fold. 152 Section 3 analyzes the feasibility of traditional address-scanning 153 attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of 154 possible improvements to such techniques. [van-Dijk] describes a 155 technique for leveraging DNS reverse mappings for discovering IPv6 156 nodes. Finally, Appendix A describes how the analysis carried out 157 throughout this document can be leveraged to produce address-scanning 158 tools (e.g. for penetration testing purposes). 160 2. Requirements for the Applicability of Network Reconnaissance 161 Techniques 163 Throughout this document, a number of network reconnaissance 164 techniques are discussed. Each of these techniques have different 165 requirements on the side of the practitioner, with respect to whether 166 they require local access to the target network, and whether they 167 require login access (or similar access credentials) to the system on 168 which the technique is applied. 170 The following table tries to summarize the aforementioned 171 requirements, and serves as a cross index to the corresponding 172 sections. 174 +---------------------------------------------+----------+----------+ 175 | Technique | Local | Login | 176 | | access | access | 177 +---------------------------------------------+----------+----------+ 178 | Local address scans (Section 3.3) | Yes | No | 179 +---------------------------------------------+----------+----------+ 180 | Remote Address scans (Section 3.2) | No | No | 181 +---------------------------------------------+----------+----------+ 182 | DNS Advertised Hosts (Section 4.1) | No | No | 183 +---------------------------------------------+----------+----------+ 184 | DNS Zone Transfers (Section 4.2) | No | No | 185 +---------------------------------------------+----------+----------+ 186 | DNS reverse mappings (Section 4.4) | No | No | 187 +---------------------------------------------+----------+----------+ 188 | Public archives (Section 6) | No | No | 189 +---------------------------------------------+----------+----------+ 190 | Application Participation (Section 7) | No | No | 191 +---------------------------------------------+----------+----------+ 192 | Inspection of the IPv6 Neighbor Cache and | No | Yes | 193 | Routing Table (Section 8) | | | 194 +---------------------------------------------+----------+----------+ 195 | Inspecting System Configuration and Log | No | Yes | 196 | Files (Section 9) | | | 197 +---------------------------------------------+----------+----------+ 198 | Gleaning information from Routing Protocols | Yes | No | 199 | (Section 10) | | | 200 +---------------------------------------------+----------+----------+ 201 | Gleaning Information from IP Flow | No | Yes | 202 | Information Export (IPFIX) (Section 11) | | | 203 +---------------------------------------------+----------+----------+ 204 | Obtaining Network Information with | No | No | 205 | traceroute6 (Section 12) | | | 206 +---------------------------------------------+----------+----------+ 208 Table 1: Requirements for the Applicability of Network Reconnaissance 209 Techniques 211 3. IPv6 Address Scanning 213 This section discusses how traditional address scanning techniques 214 (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an 215 essential analysis of how address configuration is performed in IPv6, 216 identifying patterns in IPv6 addresses that can be leveraged to 217 reduce the IPv6 address search space when performing IPv6 address 218 scans. Appendix A discusses how the insights obtained in the 219 previous sub-sections can be incorporated into into a fully-fledged 220 IPv6 address scanning tool. Section 3.5 provides advice on how to 221 mitigate IPv6 address scans. 223 3.1. Address Configuration in IPv6 225 IPv6 incorporates two automatic address-configuration mechanisms: 226 SLAAC (StateLess Address Auto-Configuration) [RFC4862] and DHCPv6 227 (Dynamic Host Configuration Protocol version 6) [RFC3315]. SLAAC is 228 the mandatory mechanism for automatic address configuration, while 229 DHCPv6 is optional - however, most current versions of general- 230 purpose operating systems support both. In addition to automatic 231 address configuration, hosts, typically servers, may employ manual 232 configuration, in which all the necessary information is manually 233 entered by the host or network administrator into configuration files 234 at the host. 236 The following subsections describe each of the possible configuration 237 mechanisms/approaches in more detail. 239 3.1.1. StateLess Address Auto-Configuration (SLAAC) 241 The basic idea behind SLAAC is that every host joining a network will 242 send a multicasted solicitation requesting network configuration 243 information, and local routers will respond to the request providing 244 the necessary information. SLAAC employs two different ICMPv6 245 message types: ICMPv6 Router Solicitation and ICMPv6 Router 246 Advertisement messages. Router Solicitation messages are employed by 247 hosts to query local routers for configuration information, while 248 Router Advertisement messages are employed by local routers to convey 249 the requested information. 251 Router Advertisement messages convey a plethora of network 252 configuration information, including the IPv6 prefix that should be 253 used for configuring IPv6 addresses on the local network. For each 254 local prefix learned from a Router Advertisement message, an IPv6 255 address is configured by appending a locally-generated Interface 256 Identifier (IID) to the corresponding IPv6 prefix. 258 The following subsections describe currently-deployed policies for 259 generating the IIDs used with SLAAC. 261 3.1.1.1. Interface-Identifiers Embedding IEEE Identifiers 263 The traditional SLAAC interface identifiers are based on the link- 264 layer address of the corresponding network interface card. For 265 example, in the case of Ethernet addresses, the IIDs are constructed 266 as follows: 268 1. The "Universal" bit (bit 6, from left to right) of the address is 269 set to 1 271 2. The word 0xfffe is inserted between the OUI (Organizationally 272 Unique Identifier) and the rest of the Ethernet address 274 For example, the MAC address 00:1b:38:83:88:3c would lead to the IID 275 021b:38ff:fe83:883c. 277 NOTE: 278 [RFC7136] notes that all bits of an IID should be treated as 279 "opaque" bits. Furthermore, [I-D.ietf-6man-default-iids] is 280 currently in the process of changing the default IID generation 281 scheme to [RFC7217]. Therefore, the traditional IIDs based on 282 link-layer addresses are expected to become less common over time. 284 A number of considerations should be made about these identifiers. 285 Firstly, as it should be obvious from the algorithm described above, 286 two bytes (bytes 4-5) of the resulting address always have a fixed 287 value (0xff, 0xfe), thus reducing the search space for the IID. 288 Secondly, the first three bytes of these identifiers correspond to 289 the OUI of the network interface card vendor. Since not all possible 290 OUIs have been assigned, this further reduces the IID search space. 291 Furthermore, of the assigned OUIs, many could be regarded as 292 corresponding to legacy devices, and thus unlikely to be used for 293 Internet-connected IPv6-enabled systems, yet further reducing the IID 294 search space. Finally, in some scenarios it could be possible to 295 infer the OUI in use by the target network devices, yet narrowing 296 down the possible IIDs even more. 298 For example, an organization known for being provisioned by vendor 299 X is likely to have most of the nodes in its organizational 300 network with OUIs corresponding to vendor X. 302 These considerations mean that in some scenarios, the original IID 303 search space of 64 bits may be effectively reduced to 2^24 , or n * 304 2^24 (where "n" is the number of different OUIs assigned to the 305 target vendor). 307 Further, if just one host address is detected or known within a 308 subnet, it is not unlikely that, if systems were ordered in a batch, 309 that they may have sequential MAC addresses. Additionally, given a 310 MAC address observed in one subnet, sequential or nearby MAC 311 addresses may be seen in other subnets in the same site. 313 Another interesting factor arises from the use of virtualization 314 technologies, since they generally employ automatically-generated MAC 315 addresses, with very specific patterns. For example, all 316 automatically-generated MAC addresses in VirtualBox virtual machines 317 employ the OUI 08:00:27 [VBox2011]. This means that all SLAAC- 318 produced addresses will have an IID of the form a00:27ff:feXX:XXXX, 319 thus effectively reducing the IID search space from 64 bits to 24 320 bits. 322 VMWare ESX server provides yet a more interesting example. 323 Automatically-generated MAC addresses have the following pattern 324 [vmesx2011]: 326 1. The OUI is set to 00:05:59 328 2. The next 16-bits of the MAC address are set to the same value as 329 the last 16 bits of the console operating system's primary IPv4 330 address 332 3. The final eight bits of the MAC address are set to a hash value 333 based on the name of the virtual machine's configuration file. 335 This means that, assuming the console operating system's primary IPv4 336 address is known, the IID search space is reduced from 64 bits to 8 337 bits. 339 On the other hand, manually-configured MAC addresses in VMWare ESX 340 server employ the OUI 00:50:56, with the low-order three bytes being 341 in the range 0x000000-0x3fffff (to avoid conflicts with other VMware 342 products). Therefore, even in the case of manually-configured MAC 343 addresses, the IID search space is reduced from 64-bits to 22 bits. 345 3.1.1.2. Temporary Addresses 347 Privacy concerns [Gont-DEEPSEC2011] 348 [I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface 349 identifiers embedding IEEE identifiers led to the introduction of 350 "Privacy Extensions for Stateless Address Auto-configuration in IPv6" 351 [RFC4941], also known as "temporary addresses" or "privacy 352 addresses". Essentially, "temporary addresses" produce random 353 addresses by concatenating a random identifier to the auto- 354 configuration IPv6 prefix advertised in a Router Advertisement. 356 In addition to their unpredictability, these addresses are 357 typically short-lived, such that even if an attacker were to learn 358 one of these addresses, they would be of use for a limited period 359 of time. A typical implementation may keep a temporary address 360 preferred for 24 hours, and configured but deprecated for seven 361 days. 363 It is important to note that "temporary addresses" are generated in 364 addition to traditional SLAAC addresses (i.e., based on IEEE 365 identifiers): traditional SLAAC addresses are meant to be employed 366 for "server-like" inbound communications, while "temporary addresses" 367 are meant to be employed for "client-like" outbound communications. 368 This means that implementation/use of "temporary addresses" does not 369 prevent an attacker from leveraging the predictability of traditional 370 SLAAC addresses, since "temporary addresses" are generated in 371 addition to (rather than as a replacement of) the traditional SLAAC 372 addresses derived from e.g. IEEE identifiers. 374 The benefit that temporary addresses offer in this context is that 375 they reduce the exposure of the SLAAC address to any third parties 376 that may observe traffic sent from a host where temporary addresses 377 are enabled and used by default. But, in the absence of firewall 378 protection for the host, its SLAAC address remains liable to be 379 scanned from offsite. 381 3.1.1.3. Randomized Stable Interface Identifiers 383 In order to mitigate the security implications arising from the 384 predictable IPv6 addresses derived from IEEE identifiers, Microsoft 385 Windows produced an alternative scheme for generating "stable 386 addresses" (in replacement of the ones embedding IEEE identifiers). 387 The aforementioned scheme is believed to be an implementation of RFC 388 4941 [RFC4941], but without regenerating the addresses over time. 389 The resulting interface IDs are constant across system bootstraps, 390 and also constant across networks. 392 Assuming no flaws in the aforementioned algorithm, this scheme would 393 remove any patterns from the SLAAC addresses. 395 However, since the resulting interface IDs are constant across 396 networks, these addresses may still be leveraged for host tracking 397 purposes [RFC7217] 398 [I-D.ietf-6man-ipv6-address-generation-privacy]. 400 The benefit of this scheme is thus that the host may be less readily 401 detected by applying heuristics to a scan, but, in the absence of 402 concurrent use of temporary addresses, the host is liable to be 403 tracked across visited networks. 405 3.1.1.4. Stable Privacy-Enhanced Addresses 407 In response to the predictability issues discussed in Section 3.1.1.1 408 and the privacy issues discussed in 409 [I-D.ietf-6man-ipv6-address-generation-privacy], the IETF has 410 standardized (in [RFC7217]) a method for generating IPv6 Interface 411 Identifiers to be used with IPv6 Stateless Address Autoconfiguration 412 (SLAAC), such that addresses configured using this method are stable 413 within each subnet, but the Interface Identifier changes when hosts 414 move from one subnet to another. The aforementioned method is meant 415 to be an alternative to generating Interface Identifiers based on 416 IEEE identifiers, such that the benefits of stable addresses can be 417 achieved without sacrificing the privacy of users. 419 Implementation of this method (in replacement of Interface 420 Identifiers based on IEEE identifiers) would eliminate any patterns 421 from the Interface ID, thus benefiting user privacy and reducing the 422 ease with which addresses can be scanned. 424 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) 426 DHC DHCPv6 can be employed as a stateful address configuration 427 mechanism, in which a server (the DHCPv6 server) leases IPv6 428 addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are 429 assigned according to a configuration-defined address range and 430 policy, with some DHCPv6 servers assigning addresses sequentially, 431 from a specific range. In such cases, addresses tend to be 432 predictable. 434 For example, if the prefix 2001:db8::/64 is used for assigning 435 addresses on the local network, the DHCPv6 server might 436 (sequentially) assign addresses from the range 2001:db8::1 - 437 2001:db8::100. 439 In most common scenarios, this means that the IID search space will 440 be reduced from the original 64 bits, to 8 or 16 bits. RFC 5157 441 recommended that DHCPv6 instead issue addresses randomly from a large 442 pool; that advice is repeated here. 443 [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that 444 can be employed by DHCPv6 servers to produce stable addresses which 445 do not follow any specific pattern, thus resulting in an IID search 446 space of 64 bits. 448 3.1.3. Manually-configured Addresses 450 In some scenarios, node addresses may be manually configured. This 451 is typically the case for IPv6 addresses assigned to routers (since 452 routers do not employ automatic address configuration) but also for 453 servers (since having a stable address that does not depend on the 454 underlying link-layer address is generally desirable). 456 While network administrators are mostly free to select the IID from 457 any value in the range 1 - 2^64, for the sake of simplicity (i.e., 458 ease of remembering) they tend to select addresses with one of the 459 following patterns: 461 o "low-byte" addresses: in which most of the bytes of the IID are 462 set to 0 (except for the least significant byte). 464 o IPv4-based addresses: in which the IID embeds the IPv4 address of 465 the network interface (as in 2001:db8::192.0.2.1) 467 o "service port" addresses: in which the IID embeds the TCP/UDP 468 service port of the main service running on that node (as in 469 2001:db8::80 or 2001:db8::25) 471 o wordy addresses: which encode words (as in 2001:db8::dead:beef) 473 Each of these patterns is discussed in detail in the following 474 subsections. 476 3.1.3.1. Low-byte Addresses 478 The most common form of low-byte addresses is that in which all the 479 the bytes of the IID (except the least significant bytes) are set to 480 zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also 481 common to find similar addresses in which the two lowest order 16-bit 482 words are set to small numbers (as in 2001::db8::1:10, 483 2001:db8::2:10, etc.). Yet it is not uncommon to find IPv6 addresses 484 in which the second lowest-order 16-bit word is set to a small value 485 in the range 0-255, while the lowest-order 16-bit word varies in the 486 range 0-65535. It should be noted that all of these address patterns 487 are generally referred to as "low-byte addresses", even when, 488 strictly speaking, it is not not only the lowest-order byte of the 489 IPv6 address that varies from one address to another. 491 In the worst-case scenario, the search space for this pattern is 2^24 492 (although most systems can be found by searching 2^16 or even 2^8 493 addresses). 495 3.1.3.2. IPv4-based Addresses 497 The most common form of these addresses is that in which an IPv4 498 address is encoded in the lowest-order 32 bits of the IPv6 address 499 (usually as a result of the notation of addresses in the form 500 2001:db8::192.0.2.1). However, it is also common for administrators 501 to encode one byte of the IPv4 address in each of the 16-bit words of 502 the IID (as in e.g. 2001:db8::192:0:2:1). 504 For obvious reasons, the search space for addresses following this 505 pattern is that of the corresponding IPv4 prefix (or twice the size 506 of that search space if both forms of "IPv4-based addresses" are to 507 be searched). 509 3.1.3.3. Service-port Addresses 511 Address following this pattern include the service port (e.g. 80 for 512 HTTP) in the lowest-order byte of the IID, and set the rest of the 513 IID to zero. There are a number of variants for this address 514 pattern: 516 o The lowest-order 16-bit word may contain the service port, and the 517 second lowest-order 16-bit word may be set to a number in the 518 range 0-255 (as in e.g. 2001:db8::1:80). 520 o The lowest-order 16-bit word may be set to a value in the range 521 0-255, while the second lowest-order 16-bit word may contain the 522 service port (as in e.g. 2001:db8::80:1). 524 o The service port itself might be encoded in decimal or in 525 hexadecimal notation (e.g., an address embedding the HTTP port 526 might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding 527 the service port as a decimal number being more common. 529 Considering a maximum of 20 popular service ports, the search space 530 for addresses following this pattern is, in the worst-case scenario, 531 20 * 2^10. 533 3.1.3.4. Wordy Addresses 535 Since IPv6 address notation allows for a number of hexadecimal 536 digits, it is not difficult to encode words into IPv6 addresses (as 537 in, e.g., 2001:db8::dead:beef). 539 Addresses following this pattern are likely to be explored by means 540 of "dictionary attacks", and therefore computing the corresponding 541 search-space is not straight-forward. 543 3.1.4. IPv6 Addresses Corresponding to Transition/Co-existence 544 Technologies 546 Some transition/co-existence technologies might be leveraged to 547 reduce the target search space of remote address-scanning attacks, 548 since they specify how the corresponding IPv6 address must be 549 generated. For example, in the case of Teredo [RFC4380], the 64-bit 550 interface identifier is generated from the IPv4 address observed at a 551 Teredo server along with a UDP port number. 553 3.1.5. IPv6 Address Assignment in Real-world Network Scenarios 555 Table 2, Table 3 and Table 4 provide a summary of the results 556 obtained by [Gont-LACSEC2013] for web servers, nameservers, and 557 mailservers, respectively. Table 5 provides a rough summary of the 558 results obtained by [Malone2008] for IPv6 routers. Table 6 provides 559 a summary of the results obtained by [Ford2013] for clients. 561 +---------------+------------+ 562 | Address type | Percentage | 563 +---------------+------------+ 564 | IEEE-based | 1.44% | 565 +---------------+------------+ 566 | Embedded-IPv4 | 25.41% | 567 +---------------+------------+ 568 | Embedded-Port | 3.06% | 569 +---------------+------------+ 570 | ISATAP | 0% | 571 +---------------+------------+ 572 | Low-byte | 56.88% | 573 +---------------+------------+ 574 | Byte-pattern | 6.97% | 575 +---------------+------------+ 576 | Randomized | 6.24% | 577 +---------------+------------+ 579 Table 2: Measured webserver addresses 581 +---------------+------------+ 582 | Address type | Percentage | 583 +---------------+------------+ 584 | IEEE-based | 0.67% | 585 +---------------+------------+ 586 | Embedded-IPv4 | 22.11% | 587 +---------------+------------+ 588 | Embedded-Port | 6.48% | 589 +---------------+------------+ 590 | ISATAP | 0% | 591 +---------------+------------+ 592 | Low-byte | 56.58% | 593 +---------------+------------+ 594 | Byte-pattern | 11.07% | 595 +---------------+------------+ 596 | Randomized | 3.09% | 597 +---------------+------------+ 599 Table 3: Measured nameserver addresses 600 +---------------+------------+ 601 | Address type | Percentage | 602 +---------------+------------+ 603 | IEEE-based | 0.48% | 604 +---------------+------------+ 605 | Embedded-IPv4 | 4.02% | 606 +---------------+------------+ 607 | Embedded-Port | 1.07% | 608 +---------------+------------+ 609 | ISATAP | 0% | 610 +---------------+------------+ 611 | Low-byte | 92.65% | 612 +---------------+------------+ 613 | Byte-pattern | 1.20% | 614 +---------------+------------+ 615 | Randomized | 0.59% | 616 +---------------+------------+ 618 Table 4: Measured mailserver addresses 620 +--------------+------------+ 621 | Address type | Percentage | 622 +--------------+------------+ 623 | Low-byte | 70% | 624 +--------------+------------+ 625 | IPv4-based | 5% | 626 +--------------+------------+ 627 | SLAAC | 1% | 628 +--------------+------------+ 629 | Wordy | <1% | 630 +--------------+------------+ 631 | Randomized | <1% | 632 +--------------+------------+ 633 | Teredo | <1% | 634 +--------------+------------+ 635 | Other | <1% | 636 +--------------+------------+ 638 Table 5: Measured router addresses 639 +---------------+------------+ 640 | Address type | Percentage | 641 +---------------+------------+ 642 | IEEE-based | 7.72% | 643 +---------------+------------+ 644 | Embedded-IPv4 | 14.31% | 645 +---------------+------------+ 646 | Embedded-Port | 0.21% | 647 +---------------+------------+ 648 | ISATAP | 1.06% | 649 +---------------+------------+ 650 | Randomized | 69.73% | 651 +---------------+------------+ 652 | Low-byte | 6.23% | 653 +---------------+------------+ 654 | Byte-pattern | 0.74% | 655 +---------------+------------+ 657 Table 6: Measured client addresses 659 It should be clear from these measurements that a very high 660 percentage of host and router addresses follow very specific 661 patterns. 663 Table 6 shows that while around 70% of clients observed in this 664 measurement appear to be using temporary addresses, there are still a 665 significant amount exposing IEEE-based addresses, and addresses using 666 embedded IPv4 (thus also revealing IPv4 addresses). 668 3.2. IPv6 Address Scanning of Remote Networks 670 While in IPv4 networks attackers have been able to get away with 671 "brute force" scanning attacks (thanks to the reduced search space), 672 successfully performing a brute-force scan of an entire /64 network 673 would be infeasible. As a result, it is expected that attackers will 674 leverage the IPv6 address patterns discussed in Section 3.1 to reduce 675 the IPv6 address search space. 677 IPv6 address scanning of remote area networks should consider an 678 additional factor not present for the IPv4 case: since the typical 679 IPv6 host subnet is a /64, scanning an entire /64 could, in theory, 680 lead to the creation of 2^64 entries in the Neighbor Cache of the 681 last-hop router. Unfortunately, a number of IPv6 implementations 682 have been found to be unable to properly handle large number of 683 entries in the Neighbor Cache, and hence these address-scan attacks 684 may have the side effect of resulting in a Denial of Service (DoS) 685 attack [CPNI-IPv6] [RFC6583]. 687 [RFC7421] discusses the "default" /64 boundary for host subnets, and 688 the assumptions surrounding it. While there are reports of a handful 689 of sites implementing host subnets of size /112 or smaller to reduce 690 concerns about the above attack, such smaller subnets are likely to 691 make address-based scanning more feasible, in addition to 692 encountering the issues with non-/64 host subnets discussed in the 693 above draft. 695 3.2.1. Reducing the subnet ID search space 697 When scanning a remote network, consideration is required to select 698 which subnet IDs to choose. A typical site might have a /48 699 allocation, which would mean up to 65,000 or so host /64 subnets to 700 be scanned. 702 However, in the same way the search space for the IID can be reduced, 703 we may also be able to reduce the subnet ID space in a number of 704 ways, by guessing likely address plan schemes, or using any 705 complementary clues that might exist from other sources or 706 observations. 708 Address plans might include use of subnets which: 710 o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64, 711 etc. 713 o Use building numbers, in hex or decimal form. 715 o Use VLAN numbers. 717 o Use IPv4 subnet number in a dual-stack target, e.g. a site with a 718 /16 for IPv4 might use /24 subnets, and the IPv6 address plan may 719 re-use the third byte as the IPv6 subnet ID. 721 o Use the service "colour", as defined for service-based prefix 722 colouring, or semantic prefixes. For example, a site using a 723 specific colouring for a specific service such as VoIP may reduce 724 the subnet ID search space for those devices. 726 In general, any subnet ID address plan may convey information, or be 727 based on known information, which may in turn be of advantage to an 728 attacker. 730 3.3. IPv6 Address Scanning of Local Networks 732 IPv6 address scanning in Local Area Networks could be considered, to 733 some extent, a completely different problem than that of scanning a 734 remote IPv6 network. The main difference is that use of link-local 735 multicast addresses can relieve the attacker of searching for unicast 736 addresses in a large IPv6 address space. 738 Obviously, a number of other network reconnaissance vectors (such 739 as network snooping, leveraging Neighbor Discovery traffic, etc.) 740 are available when scanning a local network. However, this 741 section focuses only on address-scanning attacks (a la "ping 742 sweep"). 744 An attacker can simply send probe packets to the all-nodes link-local 745 multicast address (ff02::1), such that responses are elicited from 746 all local nodes. 748 Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo 749 Request messages sent to multicast addresses, IPv6 address-scanning 750 tools typically employ a number of additional probe packets to elicit 751 responses from all the local nodes. For example, unrecognized IPv6 752 options of type 10xxxxxx elicit ICMPv6 Parameter Problem, code 2, 753 error messages. 755 Many address-scanning tools discover only IPv6 link-local addresses 756 (rather than e.g. the global addresses of the target systems): since 757 the probe packets are typically sent with the attacker's IPv6 link- 758 local address, the "victim" nodes send the response packets using the 759 IPv6 link-local address of the corresponding network interface (as 760 specified by the IPv6 address selection rules [RFC6724]). However, 761 sending multiple probe packets, with each packet employing addresses 762 from different prefixes, typically helps to overcome this limitation. 764 This technique is employed by the scan6 tool of the IPv6 Toolkit 765 package [IPv6-Toolkit]. 767 3.4. Existing IPv6 Address Scanning Tools 769 3.4.1. Remote IPv6 Network Scanners 771 IPv4 address scanning tools have traditionally carried out their task 772 for probing an entire address range (usually the entire range of a 773 target subnetwork). One might argue that the reason for which we 774 have been able to get away with such somewhat "rudimentary" 775 techniques is that the scale or challenge of the task is so small in 776 the IPv4 world, that a "brute-force" attack is "good enough". 777 However, the scale of the "address scanning" task is so large in 778 IPv6, that attackers must be very creative to be "good enough". 779 Simply sweeping an entire /64 IPv6 subnet would just not be feasible. 781 Many address scanning tools such as nmap [nmap2012] do not even 782 support sweeping an IPv6 address range. On the other hand, the 783 alive6 tool from [THC-IPV6] supports sweeping address ranges, thus 784 being able to leverage some patters found in IPv6 addresses, such as 785 the incremental addresses resulting from some DHCPv6 setups. 786 Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address 787 ranges, and can also leverage all the address patterns described in 788 Section 3.1 of this document. 790 Clearly, a limitation of many of the currently-available tools for 791 IPv6 address scanning is that they lack of an appropriately tuned 792 "heuristics engine" that can help reduce the search space, such that 793 the problem of IPv6 address scanning becomes tractable. 795 The most "advanced" IPv6 scanning technique that has been found in 796 the wild (and publicly reported) is described in [Ybema2010] (the 797 attacker seemed to be scanning specific IPv6 addresses based on some 798 specific patterns). However, the aforementioned attempt probably 799 still falls into the category of "rudimentary". 801 It should be noted that IPv6 network monitoring and management tools 802 also need to build and maintain information about the hosts in their 803 network. Such systems can no longer scan internal systems in a 804 reasonable time to build a database of connected systems. Rather, 805 such systems will need more efficient approaches, e.g. by polling 806 network devices for data held about observed IP addresses, MAC 807 addresses, physical ports used, etc. Such an approach can also 808 enhance address accountability, by mapping IPv4 and IPv6 addresses to 809 observed MAC addresses. This of course implies that any access 810 control mechanisms for querying such network devices, e.g. community 811 strings for SNMP, should be set appropriately to avoid an attacker 812 being able to gather address information remotely. 814 3.4.2. Local IPv6 Network Scanners 816 There are a variety of publicly-available local IPv6 network 817 scanners: 819 o Current versions of nmap [nmap2012] implement this functionality. 821 o THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool (alive6) that 822 implements this functionality. 824 o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) 825 that implements this functionality. 827 3.5. Mitigations 829 IPv6 address-scanning attacks can be mitigated in a number of ways. 830 A non-exhaustive list of the possible mitigations includes: 832 o Employing stable privacy-enhanced addresses [RFC7217] in 833 replacement of addresses based on IEEE identifiers, such that any 834 address patterns are eliminated. 836 o Employing Intrusion Prevention Systems (IPS) at the perimeter, 837 such that address scanning attacks can be mitigated. 839 o Enforce IPv6 packet filtering where applicable (see e.g. 840 [RFC4890]). 842 o If virtual machines are employed, and "resistance" to address 843 scanning attacks is deemed as desirable, manually-configured MAC 844 addresses can be employed, such that even if the virtual machines 845 employ IEEE-derived IIDs, they are generated from non-predictable 846 MAC addresses. 848 o When using DHCPv6, avoid use of sequential addresses. Ideally, 849 the DHCPv6 server would allocate random addresses from a large 850 pool. 852 o Use the "default" /64 size IPv6 subnet prefixes. 854 o In general, avoid being predictable in the way addresses are 855 assigned. 857 It should be noted that some of the aforementioned mitigations are 858 operational, while others depend on the availability of specific 859 protocol features (such as [RFC7217]) on the corresponding nodes. 861 Additionally, while some resistance to address scanning attacks is 862 generally desirable (particularly when lightweight mitigations are 863 available), there are scenarios in which mitigation of some address- 864 scanning vectors is unlikely to be a high-priority (if at all 865 possible). And one should always remember that security by obscurity 866 is not a reasonable defence in itself; it may only be one (relatively 867 small) layer in a broader security environment. 869 Two of the techniques discussed in this document for local address- 870 scanning attacks are those that employ multicasted ICMPv6 Echo 871 Requests and multicasted IPv6 packets containing unsupported options 872 of type 10xxxxxx. These two vectors could be easily mitigated by 873 configuring nodes to not respond to multicasted ICMPv6 Echo Request 874 (default on Windows systems), and by updating the IPv6 specifications 875 (and/or possibly configuring local nodes) such that multicasted 876 packets never elicit ICMPv6 error messages (even if they contain 877 unsupported options of type 10xxxxxx). 879 [I-D.gont-6man-ipv6-smurf-amplifier] proposes such update to the 880 IPv6 specifications. 882 In any case, when it comes to local networks, there are a variety of 883 network reconnaissance vectors. Therefore, even if address-scanning 884 vectors are mitigated, an attacker could still rely on e.g. protocols 885 employed for the so-called "opportunistic networking" (such as mDNS 886 [RFC6762]), or eventually rely on network snooping as last resort for 887 network reconnaissance. There is ongoing work in the IETF on 888 extending mDNS, or at least DNS-based service discovery, to work 889 across a whole site, rather than in just a single subnet, which will 890 have associated security implications. 892 4. Leveraging the Domain Name System (DNS) for Network Reconnaissance 894 4.1. DNS Advertised Hosts 896 Any systems that are "published" in the DNS, e.g. MX mail relays, or 897 web servers, will remain open to probing from the very fact that 898 their IPv6 addresses are publicly available. It is worth noting that 899 where the addresses used at a site follow specific patterns, 900 publishing just one address may lead to a threat upon the other 901 hosts. 903 Additionally, we note that publication of IPv6 addresses in the DNS 904 should not discourage the elimination of IPv6 address patterns: if 905 any address patterns are eliminated from addresses published in the 906 DNS, an attacker may have to rely on performing dictionary-based DNS 907 lookups in order to find all systems in a target network (which is 908 generally less reliable and more time/traffic consuming than mapping 909 nodes with predictable IPv6 addresses). 911 4.2. DNS Zone Transfers 913 A DNS zone transfer can readily provide information about potential 914 attack targets. Restricting zone transfers is thus probably more 915 important for IPv6, even if it is already good practice to restrict 916 them in the IPv4 world. 918 4.3. DNS Brute Forcing 920 Attackers may employ DNS brute-forcing techniques by testing for the 921 presence of DNS AAAA records against commonly used host names. 923 4.4. DNS Reverse Mappings 925 [van-Dijk] describes an interesting technique that employs DNS 926 reverse mappings for network reconnaissance. Essentially, the 927 attacker walks through the "ip6.arpa" zone looking up PTR records, in 928 the hopes of learning the IPv6 addresses of hosts in a given target 929 network (assuming that the reverse mappings have been configured, of 930 course). What is most interesting about this technique is that it 931 can greatly reduce the IPv6 address search space. 933 Basically, an attacker would walk the ip6.arpa zone corresponding to 934 a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for 935 "2001:db8:80::/32"), issuing queries for PTR records corresponding to 936 the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", 937 "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR 938 records for any hosts "starting" with the domain name 939 "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name 940 corresponding to the IPv6 address 2001:db8:80::1), the response would 941 contain an RCODE of 0 (no error). Otherwise, the response would 942 contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this 943 technique allows for a tremendous reduction in the "IPv6 address" 944 search space. 946 5. Leveraging Local Name Resolution and Service Discovery Services 948 A number of protocols allow for unmanaged local name resolution and 949 service. For example, multicast DNS (mDNS) [RFC6762] and DNS Service 950 Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution 951 (LLMNR) [RFC4795], are examples of such protocols. 953 Besides the Graphical User Interfaces (GUIs) included in products 954 supporting such protocols, command-line tools such as mdns-scan 955 [mdns-scan] and mzclient can help discover IPv6 hosts employing 956 mDNS/DNS-SD. 958 6. Public Archives 960 Public mailing-list archives or Usenet news messages archives may 961 prove a useful channel for an attacker, since hostnames and/or IPv6 962 addresses could be easily obtained by inspection of the (many) 963 "Received from:" or other header lines in the archived email or 964 Usenet news messages. 966 7. Application Participation 968 Peer-to-peer applications often include some centralized server which 969 coordinates the transfer of data between peers. For example, 970 BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks 971 of files, with a tracker passing information about peers with 972 available chunks of data between the peers. Such applications may 973 offer an attacker a source of peer addresses to probe. 975 8. Inspection of the IPv6 Neighbor Cache and Routing Table 977 Information about other systems connected to the local network might 978 be readily available from the Neighbor Cache [RFC4861] and/or the 979 routing table of any system connected to such network. SAVI 980 [RFC6620] also builds a cache of IPv6 and link-layer addresses 981 (without actively participating in the Neighbor Discovery packet 982 exchange), and hence is another source of similar information. 984 These data structures could be inspected either via "login" access or 985 via SNMP. While this requirement may limit the applicability of this 986 technique, there are a number of scenarios in which this technique 987 might be of use. For example, security audit tools might be provided 988 with the necessary credentials such that the Neighbor Cache and the 989 routing table of all systems for which the tool has "login" or SNMP 990 access can be automatically gleaned. On the other hand, IPv6 worms 991 [V6-WORMS] could leverage this technique for the purpose of spreading 992 on the local network, since they will typically have access to the 993 Neighbor Cache and routing table of an infected system. 995 Section 2.5.1.4 of [I-D.ietf-opsec-v6] discusses additional 996 considerations for the inspection of the IPv6 Neighbor Cache. 998 9. Inspection of System Configuration and Log Files 1000 Nodes are generally configured with the addresses of other important 1001 local computers, such as email servers, local file servers, web proxy 1002 servers, recursive DNS servers, etc. The /etc/hosts file in UNIX, 1003 SSH known_hosts files, or the Microsoft Windows registry are just 1004 some examples of places where interesting information about such 1005 systems might be found. 1007 Additionally, system log files (including web server logs, etc.) may 1008 also prove a useful channel for an attacker. 1010 While the required credentials to access the aforementioned 1011 configuration and log files may limit the applicability of this 1012 technique, there are a number of scenarios in which this technique 1013 might be of use. For example, security audit tools might be provided 1014 with the necessary credentials such that these files can be 1015 automatically accessed. On the other hand, IPv6 worms could leverage 1016 this technique for the purpose of spreading on the local network, 1017 since they will typically have access to these files on an infected 1018 system [V6-WORMS]. 1020 10. Gleaning Information from Routing Protocols 1022 Some organizational IPv6 networks employ routing protocols to 1023 dynamically maintain routing information. In such an environment, a 1024 local attacker could become a passive listener of the routing 1025 protocol, to determine other valid subnets/prefixes and some router 1026 addresses within that organization [V6-WORMS]. 1028 11. Gleaning Information from IP Flow Information Export (IPFIX) 1030 IPFIX [RFC7012] can aggregate the flows by source addresses, and 1031 hence may be leveraged for obtaining a list of "active" IPv6 1032 addresses. Additional discussion of IPFIX can be found in 1033 Section 2.5.1.2 of [I-D.ietf-opsec-v6]. 1035 12. Obtaining Network Information with traceroute6 1037 IPv6 traceroute [traceroute6] can be employed to find router 1038 addresses and valid network prefixes. 1040 13. Conclusions 1042 In this document we have discussed issues around host-based scanning 1043 of IPv6 networks. We have shown why a /64 host subnet may be more 1044 vulnerable to address-based scanning that might intuitively be 1045 thought, and how an attacker might reduce the target search space 1046 when scanning. 1048 We have described a number of mitigations against host-based 1049 scanning, including the replacement of traditional SLAAC with stable 1050 privacy-enhanced IIDs (which will require support from system 1051 vendors). We have also offered some practical guidance, around the 1052 principle of avoiding having predictability in host addressing 1053 schemes. Finally, examples of scanning approaches and tools are 1054 discussed in the Appendices. 1056 While most early IPv6-enabled networks remain dual-stack, they are 1057 more likely to be scanned and attacked over IPv4 transport, and one 1058 may argue that the IPv6-specific considerations discussed here are 1059 not of an immediate concern. However, an early IPv6 deployment 1060 within a dual-stack network may be seen by an attacker as a 1061 potentially "easier" target, if the implementation of security 1062 policies are not as strict for IPv6 (for whatever reason). As and 1063 when IPv6-only networks become more common, the considerations in 1064 this document will be of much greater importance. 1066 14. IANA Considerations 1068 There are no IANA registries within this document. The RFC-Editor 1069 can remove this section before publication of this document as an 1070 RFC. 1072 15. Security Considerations 1074 This document explores the topic of Network Reconnaissance in IPv6 1075 networks. It analyzes the feasibility of address-scan attacks in 1076 IPv6 networks, and showing that the search space for such attacks is 1077 typically much smaller than the one traditionally assumed (64 bits). 1078 Additionally, it explores a plethora of other network reconnaissance 1079 techniques, ranging from inspecting the IPv6 Network Cache of an 1080 attacker-controlled system, to gleaning information about IPv6 1081 addresses from public mailing-list archives or Peer-To-Peer (P2P) 1082 protocols. 1084 We expect traditional address-scanning attacks to become more and 1085 more elaborated (i.e., less "brute force"), and other network 1086 reconnaissance techniques to be actively explored, as global 1087 deployment of IPv6 increases and. more specifically, as more 1088 IPv6-only devices are deployed. 1090 16. Acknowledgements 1092 The authors would like to thank (in alphabetical order) Marc Heuse, 1093 Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric 1094 Vyncke, for providing valuable comments on earlier versions of this 1095 document. 1097 Part of the contents of this document are based on the results of the 1098 project "Security Assessment of the Internet Protocol version 6 1099 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK 1100 Centre for the Protection of National Infrastructure (CPNI). 1101 Fernando Gont would like to thank the UK CPNI for their continued 1102 support. 1104 17. References 1106 17.1. Normative References 1108 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1109 (IPv6) Specification", RFC 2460, December 1998. 1111 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1112 and M. Carney, "Dynamic Host Configuration Protocol for 1113 IPv6 (DHCPv6)", RFC 3315, July 2003. 1115 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1116 SAVI: First-Come, First-Served Source Address Validation 1117 Improvement for Locally Assigned IPv6 Addresses", RFC 1118 6620, May 2012. 1120 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1121 "Default Address Selection for Internet Protocol Version 6 1122 (IPv6)", RFC 6724, September 2012. 1124 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1125 Network Address Translations (NATs)", RFC 4380, February 1126 2006. 1128 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1129 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1130 September 2007. 1132 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1133 Address Autoconfiguration", RFC 4862, September 2007. 1135 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1136 Extensions for Stateless Address Autoconfiguration in 1137 IPv6", RFC 4941, September 2007. 1139 [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow 1140 Information Export (IPFIX)", RFC 7012, September 2013. 1142 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1143 Interface Identifiers", RFC 7136, February 2014. 1145 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1146 Interface Identifiers with IPv6 Stateless Address 1147 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 1149 17.2. Informative References 1151 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1152 Multicast Name Resolution (LLMNR)", RFC 4795, January 1153 2007. 1155 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1156 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1158 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 1159 5157, March 2008. 1161 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1162 Neighbor Discovery Problems", RFC 6583, March 2012. 1164 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1165 February 2013. 1167 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1168 Discovery", RFC 6763, February 2013. 1170 [I-D.gont-6man-ipv6-smurf-amplifier] 1171 Gont, F. and W. Liu, "Security Implications of IPv6 1172 Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- 1173 amplifier-03 (work in progress), March 2013. 1175 [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 1176 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 1177 in IPv6 Addressing", RFC 7421, January 2015. 1179 [I-D.ietf-6man-default-iids] 1180 Gont, F., Cooper, A., Thaler, D., and W. Will, 1181 "Recommendation on Stable IPv6 Interface Identifiers", 1182 draft-ietf-6man-default-iids-01 (work in progress), 1183 October 2014. 1185 [I-D.ietf-6man-ipv6-address-generation-privacy] 1186 Cooper, A., Gont, F., and D. Thaler, "Privacy 1187 Considerations for IPv6 Address Generation Mechanisms", 1188 draft-ietf-6man-ipv6-address-generation-privacy-03 (work 1189 in progress), January 2015. 1191 [I-D.ietf-dhc-stable-privacy-addresses] 1192 Gont, F. and W. Will, "A Method for Generating 1193 Semantically Opaque Interface Identifiers with Dynamic 1194 Host Configuration Protocol for IPv6 (DHCPv6)", draft- 1195 ietf-dhc-stable-privacy-addresses-00 (work in progress), 1196 October 2014. 1198 [I-D.ietf-opsec-v6] 1199 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 1200 Security Considerations for IPv6 Networks", draft-ietf- 1201 opsec-v6-05 (work in progress), October 2014. 1203 [CPNI-IPv6] 1204 Gont, F., "Security Assessment of the Internet Protocol 1205 version 6 (IPv6)", UK Centre for the Protection of 1206 National Infrastructure, (available on request). 1208 [V6-WORMS] 1209 Bellovin, S., Cheswick, B., and A. Keromytis, "Worm 1210 propagation strategies in an IPv6 Internet", ;login:, 1211 pages 70-76, February 2006, 1212 . 1214 [Malone2008] 1215 Malone, D., "Observations of IPv6 Addresses", Passive and 1216 Active Measurement Conference (PAM 2008, LNCS 4979), April 1217 2008, 1218 . 1220 [mdns-scan] 1221 Poettering, L., "mdns-scan(1) manual page", 2012, 1222 . 1225 [nmap2012] 1226 Fyodor, , "nmap - Network exploration tool and security / 1227 port scanner", 2012, . 1229 [VBox2011] 1230 VirtualBox, , "Oracle VM VirtualBox User Manual, version 1231 4.1.2", August 2011, . 1233 [vmesx2011] 1234 vmware, , "Setting a static MAC address for a virtual 1235 NIC", vmware Knowledge Base, August 2011, 1236 . 1239 [traceroute6] 1240 FreeBSD, , "FreeBSD System Manager's Manual: 1241 traceroute6(8) manual page", 2009, 1242 . 1244 [Ybema2010] 1245 Ybema, I., "just seen my first IPv6 network abuse scan, is 1246 this the start for more?", Post to the NANOG mailing-list, 1247 2010, . 1250 [Gont-DEEPSEC2011] 1251 Gont, F., "Results of a Security Assessment of the 1252 Internet Protocol version 6 (IPv6)", DEEPSEC 2011 1253 Conference, Vienna, Austria, November 2011, 2011, 1254 . 1257 [Gont-LACSEC2013] 1258 Gont, F., "IPv6 Network Reconnaissance: Theory & 1259 Practice", LACSEC 2013 Conference, Medellin, Colombia, May 1260 2013, 2013, 1261 . 1264 [Ford2013] 1265 Ford, M., "IPv6 Address Analysis - Privacy In, Transition 1266 Out", 2013, . 1269 [THC-IPV6] 1270 "THC-IPV6", . 1272 [IPv6-Toolkit] 1273 "SI6 Networks' IPv6 Toolkit", 1274 . 1276 [BitTorrent] 1277 "BitTorrent", . 1279 [van-Dijk] 1280 van Dijk, P., "Finding v6 hosts by efficiently mapping 1281 ip6.arpa", 2012, . 1284 Appendix A. Implementation of a full-fledged IPv6 address-scanning tool 1286 This section describes the implementation of a full-fledged IPv6 1287 address scanning tool. Appendix A.1 discusses the selection of host 1288 probes. Appendix A.2 describes the implementation of an IPv6 address 1289 scanner for local area networks. Appendix A.3 outlines ongoing work 1290 on the implementation of a general (i.e., non-local) IPv6 host 1291 scanner. 1293 A.1. Host-probing considerations 1295 A number of factors should be considered when selecting the probe 1296 types and the probing-rate for an IPv6 address scanning tool. 1298 Firstly, some hosts (or border firewalls) might be configured to 1299 block or rate-limit some specific packet types. For example, it is 1300 usual for host and router implementations to rate-limit ICMPv6 error 1301 traffic. Additionally, some firewalls might be configured to block 1302 or rate-limit incoming ICMPv6 echo request packets (see e.g. 1303 [RFC4890]). 1305 As noted earlier in this document, Windows systems simply do not 1306 respond to ICMPv6 echo requests sent to multicast IPv6 addresses. 1308 Among the possible probe types are: 1310 o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies), 1312 o TCP SYN segments (meant to elicit SYN/ACK or RST segments), 1314 o TCP segments that do not contain the ACK bit set (meant to elicit 1315 RST segments), 1317 o UDP datagrams (meant to elicit a UDP application response or an 1318 ICMPv6 Port Unreachable), 1320 o IPv6 packets containing any suitable payload and an unrecognized 1321 extension header (meant to elicit ICMPv6 Parameter Problem error 1322 messages), or, 1324 o IPv6 packets containing any suitable payload and an unrecognized 1325 option of type 10xxxxxx (such that a ICMPv6 Parameter Problem 1326 error message is elicited) 1328 Selecting an appropriate probe packet might help conceal the ongoing 1329 attack, but may also be actually necessary if host or network 1330 configuration causes certain probe packets to be dropped. In some 1331 cases, it might be desirable to insert some IPv6 extension headers 1332 before the actual payload, such that some filtering policies can be 1333 circumvented. 1335 Another factor to consider is the host-probing rate. Clearly, the 1336 higher the rate, the smaller the amount of time required to perform 1337 the attack. However, the probing-rate should not be too high, or 1338 else: 1340 1. the attack might cause network congestion, thus resulting in 1341 packet loss 1343 2. the attack might hit rate-limiting, thus resulting in packet loss 1345 3. the attack might reveal underlying problems in the Neighbor 1346 Discovery implementation, thus leading to packet loss and 1347 possibly even Denial of Service 1349 Packet-loss is undesirable, since it would mean that an "alive" node 1350 might remain undetected as a result of a lost probe or response. 1351 Such losses could be the result of congestion (in case the attacker 1352 is scanning a target network at a rate higher than the target network 1353 can handle), or may be the result of rate-limiting as it would be 1354 typically the case if ICMPv6 is employed for the probe packets. 1355 Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router 1356 implementations have been found to be unable to perform decent 1357 resource management when faced with Neighbor Discovery traffic 1358 involving a large number of local nodes. This essentially means that 1359 regardless of the type of probe packets, an address scanning attack 1360 might result in a Denial of Service (DoS) of the target network, with 1361 the same (or worse) effects as that of network congestion or rate- 1362 limiting. 1364 The specific rates at which each of these issues may come into play 1365 vary from one scenario to another, and depend on the type of deployed 1366 routers/firewalls, configuration parameters, etc. 1368 A.2. Implementation of an IPv6 local address-scanning tool 1370 scan6 [IPv6-Toolkit] is prototype IPv6 local address scanning tool, 1371 which has proven to be effective and efficient for the discovery of 1372 IPv6 hosts on a local network. 1374 The scan6 tool operates (roughly) as follows: 1376 1. The tool learns the local prefixes used for auto-configuration, 1377 an generates/configures one address for each local prefix (in 1378 addition to a link-local address). 1380 2. An ICMPv6 Echo Request message destined to the all-nodes on-link 1381 multicast address (ff02::1) is sent with each of the addresses 1382 "configured" in the previous step. Because of the different 1383 Source Addresses, each probe causes the victim nodes to use 1384 different Source Addresses for the response packets (this allows 1385 the tool to learn virtually all the addresses in use in the local 1386 network segment). 1388 3. The same procedure of the previous bullet is performed, but this 1389 time with ICMPv6 packets that contain an unrecognized option of 1390 type 10xxxxxx, such that ICMPv6 Parameter Problem error messages 1391 are elicited. This allows the tool to discover e.g. Windows 1392 nodes, which otherwise do not respond to multicasted ICMPv6 Echo 1393 Request messages. 1395 4. Each time a new "alive" address is discovered, the corresponding 1396 Interface-ID is combined with all the local prefixes, and the 1397 resulting addresses are probed (with unicasted packets). This 1398 can help to discover other addresses in use on the local network 1399 segment, since the same Interface ID is typically used with all 1400 the available prefixes for the local network. 1402 The aforementioned scheme can fail to discover some addresses for 1403 some implementation. For example, Mac OS X employs IPv6 addresses 1404 embedding IEEE-identifiers (rather than "temporary addresses") 1405 when responding to packets destined to a link-local multicast 1406 address, sourced from an on-link prefix. 1408 A.3. Implementation of a IPv6 remote address-scanning tool 1410 An IPv6 remote address scanning tool, could be implemented with the 1411 following features: 1413 o The tool can be instructed to target specific address ranges (e.g. 1414 2001:db8::0-10:0-1000) 1416 o The tool can be instructed to scan for SLAAC addresses of a 1417 specific vendor, such that only addresses embedding the 1418 corresponding IEEE OUIs are probed. 1420 o The tool can be instructed to scan for SLAAC addresses that employ 1421 a specific IEEE OUI. 1423 o The tool can be instructed to discover virtual machines, such that 1424 a given IPv6 prefix is only scanned for the address patterns 1425 resulting from virtual machines. 1427 o The tool can be instructed to scan for low-byte addresses. 1429 o The tool can be instructed to scan for wordy-addresses, in which 1430 case the tool selects addresses based on a local dictionary. 1432 o The tool can be instructed to scan for IPv6 addresses embedding 1433 TCP/UDP service ports, in which case the tool selects addresses 1434 based on a list of well-known service ports. 1436 o The tool can be specified an IPv4 address range in use at the 1437 target network, such that only IPv4-based IPv6 addresses are 1438 scanned. 1440 The scan6 tool of [IPv6-Toolkit] implements all these techniques/ 1441 features. 1443 Authors' Addresses 1444 Fernando Gont 1445 Huawei Technologies 1446 Evaristo Carriego 2644 1447 Haedo, Provincia de Buenos Aires 1706 1448 Argentina 1450 Phone: +54 11 4650 8472 1451 Email: fgont@si6networks.com 1452 URI: http://www.si6networks.com 1454 Tim Chown 1455 University of Southampton 1456 Highfield 1457 Southampton , Hampshire SO17 1BJ 1458 United Kingdom 1460 Email: tjc@ecs.soton.ac.uk