--- 1/draft-ietf-opsec-ipv6-host-scanning-07.txt 2015-08-28 06:15:01.997465677 -0700 +++ 2/draft-ietf-opsec-ipv6-host-scanning-08.txt 2015-08-28 06:15:02.065467318 -0700 @@ -1,53 +1,52 @@ opsec F. Gont Internet-Draft Huawei Technologies Obsoletes: 5157 (if approved) T. Chown Intended status: Informational University of Southampton -Expires: November 1, 2015 April 30, 2015 +Expires: February 29, 2016 August 28, 2015 Network Reconnaissance in IPv6 Networks - draft-ietf-opsec-ipv6-host-scanning-07 + draft-ietf-opsec-ipv6-host-scanning-08 Abstract IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore brute-force IPv6 address scanning attacks have been - considered unfeasible. This document updates RFC 5157, which first - discussed this assumption, by providing further analysis on how - traditional address scanning techniques apply to IPv6 networks, and - exploring some additional techniques that can be employed for IPv6 - network reconnaissance. In doing so, this document formally - obsoletes RFC 5157. + considered unfeasible. This document formally obsoletes RFC 5157, + which first discussed this assumption, by providing further analysis + on how traditional address scanning techniques apply to IPv6 + networks, and exploring some additional techniques that can be + employed for IPv6 network reconnaissance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 1, 2015. + This Internet-Draft will expire on February 29, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,112 +58,111 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements for the Applicability of Network Reconnaissance Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 3.1.2. Dynamic Host Configuration Protocol version 6 - (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10 + (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 11 3.1.4. IPv6 Addresses Corresponding to Transition/Co- - existence Technologies . . . . . . . . . . . . . . . 12 + existence Technologies . . . . . . . . . . . . . . . 14 3.1.5. IPv6 Address Assignment in Real-world Network - Scenarios . . . . . . . . . . . . . . . . . . . . . . 13 - 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 16 - 3.2.1. Reducing the subnet ID search space . . . . . . . . . 16 - 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 17 - 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 18 - 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18 - 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19 - 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 + Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 + 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17 + 3.2.1. Reducing the subnet ID search space . . . . . . . . . 17 + 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 18 + 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 19 + 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 19 + 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 20 + 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 20 4. Leveraging the Domain Name System (DNS) for Network - Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 - 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21 - 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21 - 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 + Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 21 + 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 22 + 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 22 + 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 22 5. Leveraging Local Name Resolution and Service Discovery - Services . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22 - 7. Application Participation . . . . . . . . . . . . . . . . . . 22 - 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 - 9. Inspection of System Configuration and Log Files . . . . . . 23 - 10. Gleaning Information from Routing Protocols . . . . . . . . . 23 - 11. Gleaning Information from IP Flow Information Export (IPFIX) 23 - 12. Obtaining Network Information with traceroute6 . . . . . . . 23 - 13. Gleaning Information from Network Devices Using SNMP . . . . 24 - 14. Obtaining Network Information via Traffic Snooping . . . . . 24 - 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 17. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 19.2. Informative References . . . . . . . . . . . . . . . . . 26 + Services . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 23 + 7. Application Participation . . . . . . . . . . . . . . . . . . 23 + 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 23 + 9. Inspection of System Configuration and Log Files . . . . . . 24 + 10. Gleaning Information from Routing Protocols . . . . . . . . . 24 + 11. Gleaning Information from IP Flow Information Export (IPFIX) 24 + 12. Obtaining Network Information with traceroute6 . . . . . . . 24 + 13. Gleaning Information from Network Devices Using SNMP . . . . 25 + 14. Obtaining Network Information via Traffic Snooping . . . . . 25 + 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 19.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Implementation of a full-fledged IPv6 address- - scanning tool . . . . . . . . . . . . . . . . . . . 29 - A.1. Host-probing considerations . . . . . . . . . . . . . . . 29 - A.2. Implementation of an IPv6 local address-scanning tool . . 31 - A.3. Implementation of a IPv6 remote address-scanning tool . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + scanning tool . . . . . . . . . . . . . . . . . . . 31 + A.1. Host-probing considerations . . . . . . . . . . . . . . . 31 + A.2. Implementation of an IPv6 local address-scanning tool . . 33 + A.3. Implementation of a IPv6 remote address-scanning tool . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction The main driver for IPv6 [RFC2460] deployment is its larger address space [CPNI-IPv6]. This larger address space not only allows for an increased number of connected devices, but also introduces a number of subtle changes in several aspects of the resulting networks. One of these changes is the reduced host density (the number of hosts - divided by the number of addresses) of typical IPv6 subnetworks: with - default IPv6 subnets of /64, each subnet comprises more than 1.844 * - 10^19 available addresses; however, the actual number of nodes in - each subnet is likely to remain similar to that of IPv4 subnetworks - (typically a few hundred nodes per subnet). [RFC5157] describes how - this significantly lower IPv6 host-density is likely to make classic + divided by the number of addresses) of typical IPv6 subnetworks, when + compared to their IPv4 counterparts. [RFC5157] describes how this + significantly lower IPv6 host-density is likely to make classic network address scans less feasible, since even by applying various heuristics, the address space to be scanned remains very large. RFC 5157 goes on to describe some alternative methods for attackers to glean active IPv6 addresses, and provides some guidance for administrators and implementors, e.g. not using sequential addresses with DHCPv6. - With the benefit of five years of additional IPv6 deployment - experience, this document formally updates and obsoletes RFC 5157. - It emphasises that while scanning attacks are less feasible, they - may, with appropriate heuristics, remain possible. At the time that - RFC 5157 was written, observed scans were typically across ports on - the addresses of discovered servers; since then, evidence that some + With the benefit of more than five years of additional IPv6 + deployment experience, this document formally obsoletes RFC 5157. It + emphasises that while scanning attacks are less feasible, they may, + with appropriate heuristics, remain possible. At the time that RFC + 5157 was written, observed scans were typically across ports on the + addresses of discovered servers; since then, evidence that some classic address scanning is occurring is being witnessed. This text thus updates the analysis on the feasibility of "traditional" address-scanning attacks in IPv6 networks, and it explores a number of additional techniques that can be employed for IPv6 network reconnaissance. Practical examples and guidance are also included in the Appendices. On one hand, raising awareness about IPv6 network reconnaissance techniques may allow (in some cases) network and security administrators to prevent or detect such attempts. On the other hand, network reconnaissance is essential for the so-called "penetration tests" typically performed to assess the security of production networks. As a result, we believe the benefits of a thorough discussion of IPv6 network reconnaissance are two-fold. Section 3 analyzes the feasibility of traditional address-scanning attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of - possible improvements to such techniques. [van-Dijk] describes a - technique for leveraging DNS reverse mappings for discovering IPv6 - nodes. Finally, Appendix A describes how the analysis carried out - throughout this document can be leveraged to produce address-scanning - tools (e.g. for penetration testing purposes). + possible improvements to such techniques. Appendix A describes how + the aforementioned analysis can be leveraged to produce address- + scanning tools (e.g. for penetration testing purposes). Section 4 + analyzes network reconnaissance techniques that leverage the Domain + Name System (DNS). Finally, the rest of this document discusses a + number of other miscellaneous techniques that could be leveraged for + IPv6 network reconnaissance. 2. Requirements for the Applicability of Network Reconnaissance Techniques Throughout this document, a number of network reconnaissance techniques are discussed. Each of these techniques have different requirements on the side of the practitioner, with respect to whether they require local access to the target network, and whether they require login access (or similar access credentials) to the system on which the technique is applied. @@ -282,24 +280,27 @@ For example, the MAC address 00:1b:38:83:88:3c would lead to the IID 021b:38ff:fe83:883c. NOTE: [RFC7136] notes that all bits of an IID should be treated as "opaque" bits. Furthermore, [I-D.ietf-6man-default-iids] is currently in the process of changing the default IID generation scheme to [RFC7217]. Therefore, the traditional IIDs based on link-layer addresses are expected to become less common over time. + Throughout this document we consider that bits are numbered from + left to right, starting at 0, and that bytes are numbered from + left to right, starting at 0. + A number of considerations should be made about these identifiers. - Firstly, as it should be obvious from the algorithm described above, - two bytes (bytes 4-5) of the resulting address always have a fixed - value (0xff, 0xfe), thus reducing the search space for the IID. + Firstly, two bytes (bytes 3-4) of the resulting address always have a + fixed value (0xff, 0xfe), thus reducing the search space for the IID. Secondly, the first three bytes of these identifiers correspond to the OUI of the network interface card vendor. Since not all possible OUIs have been assigned, this further reduces the IID search space. Furthermore, of the assigned OUIs, many could be regarded as corresponding to legacy devices, and thus unlikely to be used for Internet-connected IPv6-enabled systems, yet further reducing the IID search space. Finally, in some scenarios it could be possible to infer the OUI in use by the target network devices, yet narrowing down the possible IIDs even more. @@ -311,53 +312,98 @@ search space of 64 bits may be effectively reduced to 2^24 , or n * 2^24 (where "n" is the number of different OUIs assigned to the target vendor). Further, if just one host address is detected or known within a subnet, it is not unlikely that, if systems were ordered in a batch, that they may have sequential MAC addresses. Additionally, given a MAC address observed in one subnet, sequential or nearby MAC addresses may be seen in other subnets in the same site. - Another interesting factor arises from the use of virtualization - technologies, since they generally employ automatically-generated MAC - addresses, with very specific patterns. For example, all - automatically-generated MAC addresses in VirtualBox virtual machines - employ the OUI 08:00:27 [VBox2011]. This means that all SLAAC- - produced addresses will have an IID of the form a00:27ff:feXX:XXXX, - thus effectively reducing the IID search space from 64 bits to 24 - bits. +3.1.1.2. Interface-Identifiers of Virtualization Technologies - VMWare ESX server provides yet a more interesting example. - Automatically-generated MAC addresses have the following pattern - [vmesx2011]: + IIDs resulting from virtualization technologies can be considered a + specific sub-case of IIDs embedding IEEE identifiers (please see + Section 3.1.1.1): they employ IEEE identifiers, but part of the lower + half of the IID has specific patterns. The following subsections + describe IIDs of some popular virtualization technologies. - 1. The OUI is set to 00:05:59 +3.1.1.2.1. VirtualBox - 2. The next 16-bits of the MAC address are set to the same value as + All automatically-generated MAC addresses in VirtualBox virtual + machines employ the OUI 08:00:27 [VBox2011]. This means that all + SLAAC-produced addresses will have an IID of the form + a00:27ff:feXX:XXXX, thus effectively reducing the IID search space + from 64 bits to 24 bits. + +3.1.1.2.2. VMWare ESX server + + VMWare ESX server (versions 1.0 to 2.5) provides yet a more + interesting example. Automatically-generated MAC addresses have the + following pattern [vmesx2011]: + + 1. The OUI is set to 00:05:69 + + 2. The next 16 bits of the MAC address are set to the same value as the last 16 bits of the console operating system's primary IPv4 address - 3. The final eight bits of the MAC address are set to a hash value - based on the name of the virtual machine's configuration file. + 3. The final 8 bits of the MAC address are set to a hash value based + on the name of the virtual machine's configuration file. This means that, assuming the console operating system's primary IPv4 address is known, the IID search space is reduced from 64 bits to 8 bits. On the other hand, manually-configured MAC addresses in VMWare ESX server employ the OUI 00:50:56, with the low-order three bytes being - in the range 0x000000-0x3fffff (to avoid conflicts with other VMware + in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products). Therefore, even in the case of manually-configured MAC - addresses, the IID search space is reduced from 64-bits to 22 bits. + addresses, the IID search space is reduced from 64 bits to 22 bits. -3.1.1.2. Temporary Addresses +3.1.1.2.3. VMWare vSphere + + VMWare vSphere [vSphere] supports these default MAC address + generation algorithms: + + o Generated addresses + + * Assigned by vCenter Server + + * Assigned by the ESXi host + + o Manually-configured addresses + + By default, MAC addresses assigned by the vCenter server use the OUI + 00:50:56, and have the format 00:50:56:XX:YY:ZZ, where XX is + calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)), + and XX and YY are random two-digit hexadecimal numbers. Thus, the + possible IID range is 00:50:56:80:00:00-00:50:56:BF:FF:FF, and + therefore the search space for the resulting SLAAC addresses will be + 24 bits. + + MAC addresses generated by the ESXi host use the OUI 00:0C:29, and + have the format 00:0C:29:XX:YY:ZZ, where XX, YY, and ZZ are the + lastthree octets in hexadecimal format of the virtual machine UUID + (based on a hash calculated by using the UUID of the ESXi physical + machine and the path to a configuration file). Thus, the MAC + addresses will be in the range 00:0C:29:XX:YY:ZZ-00:0C:29:FF:FF:FF, + and therefore the search space for the resulting SLAAC addresses will + be 22 bits. + + Finally, manually-configured MAC addresses employ the OUI 00:50:56, + with the low-order three bytes being in the range 0x000000-0x3fffff + (to avoid conflicts with other VMware products). Therefore, + therefore the search space for the resulting SLAAC addresses will be + 22 bits. + +3.1.1.3. Temporary Addresses Privacy concerns [Gont-DEEPSEC2011] [I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface identifiers embedding IEEE identifiers led to the introduction of "Privacy Extensions for Stateless Address Auto-configuration in IPv6" [RFC4941], also known as "temporary addresses" or "privacy addresses". Essentially, "temporary addresses" produce random addresses by concatenating a random identifier to the auto- configuration IPv6 prefix advertised in a Router Advertisement. @@ -379,21 +425,21 @@ addition to (rather than as a replacement of) the traditional SLAAC addresses derived from e.g. IEEE identifiers. The benefit that temporary addresses offer in this context is that they reduce the exposure of the SLAAC address to any third parties that may observe traffic sent from a host where temporary addresses are enabled and used by default. But, in the absence of firewall protection for the host, its SLAAC address remains liable to be scanned from offsite. -3.1.1.3. Randomized Stable Interface Identifiers +3.1.1.4. Constant, semantically opaque IIDs In order to mitigate the security implications arising from the predictable IPv6 addresses derived from IEEE identifiers, Microsoft Windows produced an alternative scheme for generating "stable addresses" (in replacement of the ones embedding IEEE identifiers). The aforementioned scheme is believed to be an implementation of RFC 4941 [RFC4941], but without regenerating the addresses over time. The resulting interface IDs are constant across system bootstraps, and also constant across networks. @@ -403,21 +449,21 @@ However, since the resulting interface IDs are constant across networks, these addresses may still be leveraged for host tracking purposes [RFC7217] [I-D.ietf-6man-ipv6-address-generation-privacy]. The benefit of this scheme is thus that the host may be less readily detected by applying heuristics to a scan, but, in the absence of concurrent use of temporary addresses, the host is liable to be tracked across visited networks. -3.1.1.4. Stable Privacy-Enhanced Addresses +3.1.1.5. Stable, semantically opaque IIDs In response to the predictability issues discussed in Section 3.1.1.1 and the privacy issues discussed in [I-D.ietf-6man-ipv6-address-generation-privacy], the IETF has standardized (in [RFC7217]) a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one subnet to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on @@ -480,61 +526,64 @@ Each of these patterns is discussed in detail in the following subsections. 3.1.3.1. Low-byte Addresses The most common form of low-byte addresses is that in which all the the bytes of the IID (except the least significant bytes) are set to zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also common to find similar addresses in which the two lowest order 16-bit - words are set to small numbers (as in 2001::db8::1:10, - 2001:db8::2:10, etc.). Yet it is not uncommon to find IPv6 addresses - in which the second lowest-order 16-bit word is set to a small value - in the range 0-255, while the lowest-order 16-bit word varies in the + words (from the right to left) are set to small numbers (as in + 2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to + find IPv6 addresses in which the second lowest-order 16-bit word + (from right to left) is set to a small value in the range 0-255, + while the lowest-order 16-bit word (from right to left) varies in the range 0-65535. It should be noted that all of these address patterns are generally referred to as "low-byte addresses", even when, - strictly speaking, it is not not only the lowest-order byte of the - IPv6 address that varies from one address to another. + strictly speaking, it is not only the lowest-order byte of the IPv6 + address that varies from one address to another. In the worst-case scenario, the search space for this pattern is 2^24 (although most systems can be found by searching 2^16 or even 2^8 addresses). 3.1.3.2. IPv4-based Addresses The most common form of these addresses is that in which an IPv4 address is encoded in the lowest-order 32 bits of the IPv6 address (usually as a result of the notation of addresses in the form 2001:db8::192.0.2.1). However, it is also common for administrators to encode one byte of the IPv4 address in each of the 16-bit words of the IID (as in e.g. 2001:db8::192:0:2:1). - For obvious reasons, the search space for addresses following this - pattern is that of the corresponding IPv4 prefix (or twice the size - of that search space if both forms of "IPv4-based addresses" are to - be searched). + Therefore, the search space for addresses following this pattern is + that of the corresponding IPv4 prefix (or twice the size of that + search space if both forms of "IPv4-based addresses" are to be + searched). 3.1.3.3. Service-port Addresses Address following this pattern include the service port (e.g. 80 for HTTP) in the lowest-order byte of the IID, and set the rest of the IID to zero. There are a number of variants for this address pattern: - o The lowest-order 16-bit word may contain the service port, and the - second lowest-order 16-bit word may be set to a number in the - range 0-255 (as in e.g. 2001:db8::1:80). + o The lowest-order 16-bit word (from right to left) may contain the + service port, and the second lowest-order 16-bit word (from right + to left) may be set to a number in the range 0-255 (as in e.g. + 2001:db8::1:80). - o The lowest-order 16-bit word may be set to a value in the range - 0-255, while the second lowest-order 16-bit word may contain the - service port (as in e.g. 2001:db8::80:1). + o The lowest-order 16-bit word (from right to left) may be set to a + value in the range 0-255, while the second lowest-order 16-bit + word (from right to left) may contain the service port (as in e.g. + 2001:db8::80:1). o The service port itself might be encoded in decimal or in hexadecimal notation (e.g., an address embedding the HTTP port might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding the service port as a decimal number being more common. Considering a maximum of 20 popular service ports, the search space for addresses following this pattern is, in the worst-case scenario, 20 * 2^10. @@ -748,25 +797,24 @@ attacker. 3.3. IPv6 Address Scanning of Local Networks IPv6 address scanning in Local Area Networks could be considered, to some extent, a completely different problem than that of scanning a remote IPv6 network. The main difference is that use of link-local multicast addresses can relieve the attacker of searching for unicast addresses in a large IPv6 address space. - Obviously, a number of other network reconnaissance vectors (such - as network snooping, leveraging Neighbor Discovery traffic, etc.) - are available when scanning a local network. However, this - section focuses only on address-scanning attacks (a la "ping - sweep"). + While a number of other network reconnaissance vectors (such as + network snooping, leveraging Neighbor Discovery traffic, etc.) are + available when scanning a local network, this section focuses only + on address-scanning attacks (a la "ping sweep"). An attacker can simply send probe packets to the all-nodes link-local multicast address (ff02::1), such that responses are elicited from all local nodes. Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo Request messages sent to multicast addresses, IPv6 address-scanning tools typically employ a number of additional probe packets to elicit responses from all the local nodes. For example, unrecognized IPv6 options of type 10xxxxxx elicit ICMPv6 Parameter Problem, code 2, @@ -794,21 +842,21 @@ have been able to get away with such somewhat "rudimentary" techniques is that the scale or challenge of the task is so small in the IPv4 world, that a "brute-force" attack is "good enough". However, the scale of the "address scanning" task is so large in IPv6, that attackers must be very creative to be "good enough". Simply sweeping an entire /64 IPv6 subnet would just not be feasible. Many address scanning tools such as nmap [nmap2012] do not even support sweeping an IPv6 address range. On the other hand, the alive6 tool from [THC-IPV6] supports sweeping address ranges, thus - being able to leverage some patters found in IPv6 addresses, such as + being able to leverage some patterns found in IPv6 addresses, such as the incremental addresses resulting from some DHCPv6 setups. Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address ranges, and can also leverage all the address patterns described in Section 3.1 of this document. Clearly, a limitation of many of the currently-available tools for IPv6 address scanning is that they lack of an appropriately tuned "heuristics engine" that can help reduce the search space, such that the problem of IPv6 address scanning becomes tractable. @@ -836,21 +884,21 @@ implements this functionality. o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) that implements this functionality. 3.5. Mitigations IPv6 address-scanning attacks can be mitigated in a number of ways. A non-exhaustive list of the possible mitigations includes: - o Employing stable privacy-enhanced addresses [RFC7217] in + o Employing [RFC7217] (stable, semantically opaque IIDs) in replacement of addresses based on IEEE identifiers, such that any address patterns are eliminated. o Employing Intrusion Prevention Systems (IPS) at the perimeter, such that address scanning attacks can be mitigated. o Enforce IPv6 packet filtering where applicable (see e.g. [RFC4890]). o If virtual machines are employed, and "resistance" to address @@ -1075,21 +1123,21 @@ 15. Conclusions In this document we have discussed issues around host-based scanning of IPv6 networks. We have shown why a /64 host subnet may be more vulnerable to address-based scanning that might intuitively be thought, and how an attacker might reduce the target search space when scanning. We have described a number of mitigations against host-based scanning, including the replacement of traditional SLAAC with stable - privacy-enhanced IIDs (which will require support from system + semantically-opaque IIDs (which will require support from system vendors). We have also offered some practical guidance, around the principle of avoiding having predictability in host addressing schemes. Finally, examples of scanning approaches and tools are discussed in the Appendices. While most early IPv6-enabled networks remain dual-stack, they are more likely to be scanned and attacked over IPv4 transport, and one may argue that the IPv6-specific considerations discussed here are not of an immediate concern. However, an early IPv6 deployment within a dual-stack network may be seen by an attacker as a @@ -1121,134 +1169,158 @@ reconnaissance techniques to be actively explored, as global deployment of IPv6 increases and. more specifically, as more IPv6-only devices are deployed. 18. Acknowledgements The authors would like to thank Ray Hunter, who provided valuable text that was readily incorporated into Section 3.2.1 of this document. - The authors would like to thank (in alphabetical order) Wesley - George, Marc Heuse, Ray Hunter, Libor Polcak, Tomoyuki Sahara, Jan - Schaumann, Arturo Servin, and Eric Vyncke, for providing valuable - comments on earlier versions of this document. + The authors would like to thank (in alphabetical order) Alissa + Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse, + Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki + Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke, for providing + valuable comments on earlier versions of this document. Part of the contents of this document are based on the results of the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). - Fernando Gont would like to thank the UK CPNI for their continued - support. 19. References 19.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., - and M. Carney, "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, . [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation - Improvement for Locally Assigned IPv6 Addresses", RFC - 6620, May 2012. + Improvement for Locally Assigned IPv6 Addresses", + RFC 6620, DOI 10.17487/RFC6620, May 2012, + . - [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 - (IPv6)", RFC 6724, September 2012. + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + . [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through - Network Address Translations (NATs)", RFC 4380, February - 2006. + Network Address Translations (NATs)", RFC 4380, + DOI 10.17487/RFC4380, February 2006, + . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, - September 2007. + DOI 10.17487/RFC4861, September 2007, + . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless - Address Autoconfiguration", RFC 4862, September 2007. + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in - IPv6", RFC 4941, September 2007. + IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, + . - [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow - Information Export (IPFIX)", RFC 7012, September 2013. + [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model + for IP Flow Information Export (IPFIX)", RFC 7012, + DOI 10.17487/RFC7012, September 2013, + . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 - Interface Identifiers", RFC 7136, February 2014. + Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, + February 2014, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address - Autoconfiguration (SLAAC)", RFC 7217, April 2014. + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + . 19.2. Informative References [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local - Multicast Name Resolution (LLMNR)", RFC 4795, January - 2007. + Multicast Name Resolution (LLMNR)", RFC 4795, + DOI 10.17487/RFC4795, January 2007, + . [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering - ICMPv6 Messages in Firewalls", RFC 4890, May 2007. + ICMPv6 Messages in Firewalls", RFC 4890, + DOI 10.17487/RFC4890, May 2007, + . - [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC - 5157, March 2008. + [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", + RFC 5157, DOI 10.17487/RFC5157, March 2008, + . [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment - Considerations", RFC 5375, December 2008. + Considerations", RFC 5375, DOI 10.17487/RFC5375, December + 2008, . [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational - Neighbor Discovery Problems", RFC 6583, March 2012. + Neighbor Discovery Problems", RFC 6583, + DOI 10.17487/RFC6583, March 2012, + . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, - February 2013. + DOI 10.17487/RFC6762, February 2013, + . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service - Discovery", RFC 6763, February 2013. + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + . [I-D.gont-6man-ipv6-smurf-amplifier] Gont, F. and W. Liu, "Security Implications of IPv6 Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- amplifier-03 (work in progress), March 2013. [I-D.howard-isp-ip6rdns] Howard, L., "Reverse DNS in IPv6 for Internet Service - Providers", draft-howard-isp-ip6rdns-07 (work in - progress), February 2015. + Providers", draft-howard-isp-ip6rdns-08 (work in + progress), May 2015. - [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, - A., and A. Yourtchenko, "Analysis of the 64-bit Boundary - in IPv6 Addressing", RFC 7421, January 2015. + [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., + Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit + Boundary in IPv6 Addressing", RFC 7421, + DOI 10.17487/RFC7421, January 2015, + . [I-D.ietf-6man-default-iids] - Gont, F., Cooper, A., Thaler, D., and W. Will, + Gont, F., Cooper, A., Thaler, D., and S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", - draft-ietf-6man-default-iids-02 (work in progress), - January 2015. + draft-ietf-6man-default-iids-07 (work in progress), August + 2015. [I-D.ietf-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", - draft-ietf-6man-ipv6-address-generation-privacy-05 (work - in progress), April 2015. + draft-ietf-6man-ipv6-address-generation-privacy-07 (work + in progress), June 2015. [I-D.ietf-dhc-stable-privacy-addresses] - Gont, F. and W. Will, "A Method for Generating - Semantically Opaque Interface Identifiers with Dynamic - Host Configuration Protocol for IPv6 (DHCPv6)", draft- - ietf-dhc-stable-privacy-addresses-02 (work in progress), - April 2015. + Gont, F. and S. LIU, "A Method for Generating Semantically + Opaque Interface Identifiers with Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- + stable-privacy-addresses-02 (work in progress), April + 2015. [I-D.ietf-opsec-v6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", draft-ietf- opsec-v6-06 (work in progress), March 2015. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). @@ -1277,36 +1349,41 @@ [VBox2011] VirtualBox, , "Oracle VM VirtualBox User Manual, version 4.1.2", August 2011, . [vmesx2011] vmware, , "Setting a static MAC address for a virtual NIC", vmware Knowledge Base, August 2011, . + [vSphere] vmware, , "vSphere Networking", 2014, + . + [traceroute6] FreeBSD, , "FreeBSD System Manager's Manual: traceroute6(8) manual page", 2009, . [Gont-DEEPSEC2011] Gont, F., "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, 2011, . [Gont-LACSEC2013] Gont, F., "IPv6 Network Reconnaissance: Theory & - Practice", LACSEC 2013 Conference, Medellin, Colombia, May - 2013, 2013, + Practice", LACSEC 2013 Conference, Medellin, Colombia, + May 2013, 2013, . [Ford2013] Ford, M., "IPv6 Address Analysis - Privacy In, Transition Out", 2013, . [THC-IPV6] "THC-IPV6", .