draft-ietf-opsec-ipv6-host-scanning-04.txt   draft-ietf-opsec-ipv6-host-scanning-05.txt 
opsec F. Gont opsec F. Gont
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 5157 (if approved) T. Chown Obsoletes: 5157 (if approved) T. Chown
Intended status: Informational University of Southampton Intended status: Informational University of Southampton
Expires: December 16, 2014 June 14, 2014 Expires: July 23, 2015 January 19, 2015
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-04 draft-ietf-opsec-ipv6-host-scanning-05
Abstract Abstract
IPv6 offers a much larger address space than that of its IPv4 IPv6 offers a much larger address space than that of its IPv4
counterpart. An IPv6 subnet of size /64 can (in theory) accommodate counterpart. An IPv6 subnet of size /64 can (in theory) accommodate
approximately 1.844 * 10^19 hosts, thus resulting in a much lower approximately 1.844 * 10^19 hosts, thus resulting in a much lower
host density (#hosts/#addresses) than is typical in IPv4 networks, host density (#hosts/#addresses) than is typical in IPv4 networks,
where a site typically has 65,000 or less unique addresses. As a 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 result, it is widely assumed that it would take a tremendous effort
to perform address scanning attacks against IPv6 networks, and to perform address scanning attacks against IPv6 networks, and
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2014. This Internet-Draft will expire on July 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for the Applicability of Network Reconnaissance 2. Requirements for the Applicability of Network Reconnaissance
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5
3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 5 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6
3.1.2. Dynamic Host Configuration Protocol version 6 3.1.2. Dynamic Host Configuration Protocol version 6
(DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10
3.1.4. IPv6 Addresses Corresponding to Transition/Co- 3.1.4. IPv6 Addresses Corresponding to Transition/Co-
existence Technologies . . . . . . . . . . . . . . . 12 existence Technologies . . . . . . . . . . . . . . . 12
3.1.5. IPv6 Address Assignment in Real-world Network 3.1.5. IPv6 Address Assignment in Real-world Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 12 Scenarios . . . . . . . . . . . . . . . . . . . . . . 13
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15
3.2.1. Reducing the subnet ID search space . . . . . . . . . 16 3.2.1. Reducing the subnet ID search space . . . . . . . . . 16
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 17 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 17
3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 17 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 17
3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 18 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 18
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 20 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 20
4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 20 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 20
4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21
7. Application Participation . . . . . . . . . . . . . . . . . . 22 7. Application Participation . . . . . . . . . . . . . . . . . . 21
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22
9. Inspection of System Configuration and Log Files . . . . . . 22 9. Inspection of System Configuration and Log Files . . . . . . 22
10. Gleaning Information from Routing Protocols . . . . . . . . . 23 10. Gleaning Information from Routing Protocols . . . . . . . . . 23
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Gleaning Information from IP Flow Information Export (IPFIX) 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. Obtaining Network Information with traceroute6 . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15.1. Normative References . . . . . . . . . . . . . . . . . . 24 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
15.2. Informative References . . . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
17.1. Normative References . . . . . . . . . . . . . . . . . . 24
17.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Implementation of a full-fledged IPv6 address- Appendix A. Implementation of a full-fledged IPv6 address-
scanning tool . . . . . . . . . . . . . . . . . . . 27 scanning tool . . . . . . . . . . . . . . . . . . . 28
A.1. Host-probing considerations . . . . . . . . . . . . . . . 27 A.1. Host-probing considerations . . . . . . . . . . . . . . . 28
A.2. Implementation of an IPv6 local address-scanning tool . . 29 A.2. Implementation of an IPv6 local address-scanning tool . . 30
A.3. Implementation of a IPv6 remote address-scanning tool . . 30 A.3. Implementation of a IPv6 remote address-scanning tool . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The main driver for IPv6 [RFC2460] deployment is its larger address The main driver for IPv6 [RFC2460] deployment is its larger address
space [CPNI-IPv6]. This larger address space not only allows for an space [CPNI-IPv6]. This larger address space not only allows for an
increased number of connected devices, but also introduces a number increased number of connected devices, but also introduces a number
of subtle changes in several aspects of the resulting networks. One of subtle changes in several aspects of the resulting networks. One
of these changes is the reduced host density (the number of hosts of these changes is the reduced host density (the number of hosts
divided by the number of addresses) of typical IPv6 subnetworks: with divided by the number of addresses) of typical IPv6 subnetworks: with
skipping to change at page 4, line 16 skipping to change at page 4, line 18
techniques may allow (in some cases) network and security techniques may allow (in some cases) network and security
administrators to prevent or detect such attempts. On the other administrators to prevent or detect such attempts. On the other
hand, network reconnaissance is essential for the so-called hand, network reconnaissance is essential for the so-called
"penetration tests" typically performed to assess the security of "penetration tests" typically performed to assess the security of
production networks. As a result, we believe the benefits of a production networks. As a result, we believe the benefits of a
thorough discussion of IPv6 network reconnaissance are two-fold. thorough discussion of IPv6 network reconnaissance are two-fold.
Section 3 analyzes the feasibility of traditional address-scanning Section 3 analyzes the feasibility of traditional address-scanning
attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of
possible improvements to such techniques. [van-Dijk] describes a possible improvements to such techniques. [van-Dijk] describes a
recently-disclosed technique for leveraging DNS reverse mappings for technique for leveraging DNS reverse mappings for discovering IPv6
discovering IPv6 nodes. Finally, Appendix A describes how the nodes. Finally, Appendix A describes how the analysis carried out
analysis carried out throughout this document can be leveraged to throughout this document can be leveraged to produce address-scanning
produce address-scanning tools (e.g. for penetration testing tools (e.g. for penetration testing purposes).
purposes).
2. Requirements for the Applicability of Network Reconnaissance 2. Requirements for the Applicability of Network Reconnaissance
Techniques Techniques
Throughout this document, a number of network reconnaissance Throughout this document, a number of network reconnaissance
techniques are discussed. Each of these techniques have different techniques are discussed. Each of these techniques have different
requirements on the side of the practitioner, with respect to whether requirements on the side of the practitioner, with respect to whether
they require local access to the target network, and whether they they require local access to the target network, and whether they
require login access to the system on which the technique is applied. require login access (or similar access credentials) to the system on
which the technique is applied.
The following table tries to summarize the aforementioned The following table tries to summarize the aforementioned
requirements, and serves as a cross index to the corresponding requirements, and serves as a cross index to the corresponding
sections. sections.
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Technique | Local | Login | | Technique | Local | Login |
| | access | access | | | access | access |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Local address scans (Section 3.3) | Yes | No | | Local address scans (Section 3.3) | Yes | No |
skipping to change at page 5, line 32 skipping to change at page 5, line 32
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Inspection of the IPv6 Neighbor Cache and | No | Yes | | Inspection of the IPv6 Neighbor Cache and | No | Yes |
| Routing Table (Section 8) | | | | Routing Table (Section 8) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Inspecting System Configuration and Log | No | Yes | | Inspecting System Configuration and Log | No | Yes |
| Files (Section 9) | | | | Files (Section 9) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning information from Routing Protocols | Yes | No | | Gleaning information from Routing Protocols | Yes | No |
| (Section 10) | | | | (Section 10) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning Information from IP Flow | No | Yes |
| Information Export (IPFIX) (Section 11) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information with | No | No |
| traceroute6 (Section 12) | | |
+---------------------------------------------+----------+----------+
Table 1: Requirements for the Applicability of Network Reconnaissance Table 1: Requirements for the Applicability of Network Reconnaissance
Techniques Techniques
3. IPv6 Address Scanning 3. IPv6 Address Scanning
This section discusses how traditional address scanning techniques This section discusses how traditional address scanning techniques
(e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an
essential analysis of how address configuration is performed in IPv6, essential analysis of how address configuration is performed in IPv6,
identifying patterns in IPv6 addresses that can be leveraged to identifying patterns in IPv6 addresses that can be leveraged to
skipping to change at page 8, line 26 skipping to change at page 8, line 32
bits. bits.
On the other hand, manually-configured MAC addresses in VMWare ESX 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 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 0x000000-0x3fffff (to avoid conflicts with other VMware
products). Therefore, even in the case of manually-configured MAC 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. Temporary Addresses
Privacy concerns [CPNI-IPv6] [Gont-DEEPSEC2011] regarding interface Privacy concerns [Gont-DEEPSEC2011]
[I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface
identifiers embedding IEEE identifiers led to the introduction of identifiers embedding IEEE identifiers led to the introduction of
"Privacy Extensions for Stateless Address Auto-configuration in IPv6" "Privacy Extensions for Stateless Address Auto-configuration in IPv6"
[RFC4941], also known as "temporary addresses" or "privacy [RFC4941], also known as "temporary addresses" or "privacy
addresses". Essentially, "temporary addresses" produce random addresses". Essentially, "temporary addresses" produce random
addresses by concatenating a random identifier to the auto- addresses by concatenating a random identifier to the auto-
configuration IPv6 prefix advertised in a Router Advertisement. configuration IPv6 prefix advertised in a Router Advertisement.
In addition to their unpredictability, these addresses are In addition to their unpredictability, these addresses are
typically short-lived, such that even if an attacker were to learn typically short-lived, such that even if an attacker were to learn
one of these addresses, they would be of use for a limited period one of these addresses, they would be of use for a limited period
skipping to change at page 10, line 9 skipping to change at page 10, line 15
IEEE identifiers, such that the benefits of stable addresses can be IEEE identifiers, such that the benefits of stable addresses can be
achieved without sacrificing the privacy of users. achieved without sacrificing the privacy of users.
Implementation of this method (in replacement of Interface Implementation of this method (in replacement of Interface
Identifiers based on IEEE identifiers) would eliminate any patterns Identifiers based on IEEE identifiers) would eliminate any patterns
from the Interface ID, thus benefiting user privacy and reducing the from the Interface ID, thus benefiting user privacy and reducing the
ease with which addresses can be scanned. ease with which addresses can be scanned.
3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6)
DHCPv6 can be employed as a stateful address configuration mechanism, DHC DHCPv6 can be employed as a stateful address configuration
in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 mechanism, in which a server (the DHCPv6 server) leases IPv6
hosts. As with the IPv4 counterpart, addresses are assigned addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are
according to a configuration-defined address range and policy, with assigned according to a configuration-defined address range and
some DHCPv6 servers assigned addresses sequentially, from a specific policy, with some DHCPv6 servers assigning addresses sequentially,
range. In such cases, addresses tend to be predictable. from a specific range. In such cases, addresses tend to be
predictable.
For example, if the prefix 2001:db8::/64 is used for assigning For example, if the prefix 2001:db8::/64 is used for assigning
addresses on the local network, the DHCPv6 server might addresses on the local network, the DHCPv6 server might
(sequentially) assign addresses from the range 2001:db8::1 - (sequentially) assign addresses from the range 2001:db8::1 -
2001:db8::100. 2001:db8::100.
In most common scenarios, this means that the IID search space will In most common scenarios, this means that the IID search space will
be reduced from the original 64 bits, to 8 or 16 bits. RFC 5157 be reduced from the original 64 bits, to 8 or 16 bits. RFC 5157
recommended that DHCPv6 instead issue addresses randomly from a large recommended that DHCPv6 instead issue addresses randomly from a large
pool; that advice is repeated here. pool; that advice is repeated here.
[I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that
can be employed by DHCPv6 servers to produce stable addresses which
do not follow any specific pattern, thus resulting in an IID search
space of 64 bits.
3.1.3. Manually-configured Addresses 3.1.3. Manually-configured Addresses
In some scenarios, node addresses may be manually configured. This In some scenarios, node addresses may be manually configured. This
is typically the case for IPv6 addresses assigned to routers (since is typically the case for IPv6 addresses assigned to routers (since
routers do not employ automatic address configuration) but also for routers do not employ automatic address configuration) but also for
servers (since having a stable address that does not depend on the servers (since having a stable address that does not depend on the
underlying link-layer address is generally desirable). underlying link-layer address is generally desirable).
While network administrators are mostly free to select the IID from While network administrators are mostly free to select the IID from
skipping to change at page 16, line 5 skipping to change at page 16, line 5
IPv6 address scanning of remote area networks should consider an IPv6 address scanning of remote area networks should consider an
additional factor not present for the IPv4 case: since the typical additional factor not present for the IPv4 case: since the typical
IPv6 host subnet is a /64, scanning an entire /64 could, in theory, IPv6 host subnet is a /64, scanning an entire /64 could, in theory,
lead to the creation of 2^64 entries in the Neighbor Cache of the lead to the creation of 2^64 entries in the Neighbor Cache of the
last-hop router. Unfortunately, a number of IPv6 implementations last-hop router. Unfortunately, a number of IPv6 implementations
have been found to be unable to properly handle large number of have been found to be unable to properly handle large number of
entries in the Neighbor Cache, and hence these address-scan attacks entries in the Neighbor Cache, and hence these address-scan attacks
may have the side effect of resulting in a Denial of Service (DoS) may have the side effect of resulting in a Denial of Service (DoS)
attack [CPNI-IPv6] [RFC6583]. attack [CPNI-IPv6] [RFC6583].
[I-D.ietf-6man-why64] discusses the "default" /64 boundary for host [RFC7421] discusses the "default" /64 boundary for host subnets, and
subnets, and the assumptions surrounding it. While there are reports the assumptions surrounding it. While there are reports of a handful
of a handful of sites implementing host subnets of size /112 or of sites implementing host subnets of size /112 or smaller to reduce
smaller to reduce concerns about the above attack, such smaller concerns about the above attack, such smaller subnets are likely to
subnets are likely to make address-based scanning more feasible, in make address-based scanning more feasible, in addition to
addition to encountering the issues with non-/64 host subnets encountering the issues with non-/64 host subnets discussed in the
discussed in the above draft. above draft.
3.2.1. Reducing the subnet ID search space 3.2.1. Reducing the subnet ID search space
When scanning a remote network, consideration is required to select When scanning a remote network, consideration is required to select
which subnet IDs to choose. A typical site might have a /48 which subnet IDs to choose. A typical site might have a /48
allocation, which would mean up to 65,000 or so host /64 subnets to allocation, which would mean up to 65,000 or so host /64 subnets to
be scanned. be scanned.
However, just as with the search space within a host IID being able However, in the same way the search space for the IID can be reduced,
to be reduced, we may also be able to reduce the subnet ID space in a we may also be able to reduce the subnet ID space in a number of
number of ways, by guessing likely address plan schemes, or using any ways, by guessing likely address plan schemes, or using any
complementary clues that might exist from other sources or complementary clues that might exist from other sources or
observations. observations.
Address plans might include use of subnets which: Address plans might include use of subnets which:
o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64, o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64,
etc. etc.
o Use building numbers, in hex or decimal form. o Use building numbers, in hex or decimal form.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
important for IPv6, even if it is already good practice to restrict important for IPv6, even if it is already good practice to restrict
them in the IPv4 world. them in the IPv4 world.
4.3. DNS Brute Forcing 4.3. DNS Brute Forcing
Attackers may employ DNS brute-forcing techniques by testing for the Attackers may employ DNS brute-forcing techniques by testing for the
presence of DNS AAAA records against commonly used host names. presence of DNS AAAA records against commonly used host names.
4.4. DNS Reverse Mappings 4.4. DNS Reverse Mappings
An interesting technique that employs DNS reverse mappings for [van-Dijk] describes an interesting technique that employs DNS
network reconnaissance has been recently disclosed [van-Dijk]. reverse mappings for network reconnaissance. Essentially, the
Essentially, the attacker walks through the "ip6.arpa" zone looking attacker walks through the "ip6.arpa" zone looking up PTR records, in
up PTR records, in the hopes of learning the IPv6 addresses of hosts the hopes of learning the IPv6 addresses of hosts in a given target
in a given target network (assuming that the reverse mappings have network (assuming that the reverse mappings have been configured, of
been configured, of course). What is most interesting about this course). What is most interesting about this technique is that it
technique is that it can greatly reduce the IPv6 address search can greatly reduce the IPv6 address search space.
space.
Basically, an attacker would walk the ip6.arpa zone corresponding to Basically, an attacker would walk the ip6.arpa zone corresponding to
a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for
"2001:db8:80::/32"), issuing queries for PTR records corresponding to "2001:db8:80::/32"), issuing queries for PTR records corresponding to
the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.",
"1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR
records for any hosts "starting" with the domain name records for any hosts "starting" with the domain name
"0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name
corresponding to the IPv6 address 2001:db8:80::1), the response would corresponding to the IPv6 address 2001:db8:80::1), the response would
contain an RCODE of 0 (no error). Otherwise, the response would contain an RCODE of 0 (no error). Otherwise, the response would
skipping to change at page 22, line 18 skipping to change at page 22, line 12
coordinates the transfer of data between peers. For example, coordinates the transfer of data between peers. For example,
BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks
of files, with a tracker passing information about peers with of files, with a tracker passing information about peers with
available chunks of data between the peers. Such applications may available chunks of data between the peers. Such applications may
offer an attacker a source of peer addresses to probe. offer an attacker a source of peer addresses to probe.
8. Inspection of the IPv6 Neighbor Cache and Routing Table 8. Inspection of the IPv6 Neighbor Cache and Routing Table
Information about other systems connected to the local network might Information about other systems connected to the local network might
be readily available from the Neighbor Cache [RFC4861] and/or the be readily available from the Neighbor Cache [RFC4861] and/or the
routing table of any system connected to such network. routing table of any system connected to such network. SAVI
[RFC6620] also builds a cache of IPv6 and link-layer addresses
(without actively participating in the Neighbor Discovery packet
exchange), and hence is another source of similar information.
While the requirement of having "login" access to a system in the These data structures could be inspected either via "login" access or
target network may limit the applicability of this technique, there via SNMP. While this requirement may limit the applicability of this
are a number of scenarios in which this technique might be of use. technique, there are a number of scenarios in which this technique
For example, security audit tools might be provided with the might be of use. For example, security audit tools might be provided
necessary credentials such that the Neighbor Cache and the routing with the necessary credentials such that the Neighbor Cache and the
table of all systems for which the tool has "login" access can be routing table of all systems for which the tool has "login" or SNMP
automatically gleaned. On the other hand, IPv6 worms [V6-WORMS] access can be automatically gleaned. On the other hand, IPv6 worms
could leverage this technique for the purpose of spreading on the [V6-WORMS] could leverage this technique for the purpose of spreading
local network, since they will typically have access to the Neighbor on the local network, since they will typically have access to the
Cache and routing table of an infected system. Neighbor Cache and routing table of an infected system.
Section 2.5.1.4 of [I-D.ietf-opsec-v6] discusses additional
considerations for the inspection of the IPv6 Neighbor Cache.
9. Inspection of System Configuration and Log Files 9. Inspection of System Configuration and Log Files
Nodes are generally configured with the addresses of other important Nodes are generally configured with the addresses of other important
local computers, such as email servers, local file servers, web proxy local computers, such as email servers, local file servers, web proxy
servers, recursive DNS servers, etc. The /etc/hosts file in UNIX, servers, recursive DNS servers, etc. The /etc/hosts file in UNIX,
SSH known_hosts files, or the Microsoft Windows registry are just SSH known_hosts files, or the Microsoft Windows registry are just
some examples of places where interesting information about such some examples of places where interesting information about such
systems might be found. systems might be found.
skipping to change at page 23, line 10 skipping to change at page 23, line 10
automatically accessed. On the other hand, IPv6 worms could leverage automatically accessed. On the other hand, IPv6 worms could leverage
this technique for the purpose of spreading on the local network, this technique for the purpose of spreading on the local network,
since they will typically have access to these files on an infected since they will typically have access to these files on an infected
system [V6-WORMS]. system [V6-WORMS].
10. Gleaning Information from Routing Protocols 10. Gleaning Information from Routing Protocols
Some organizational IPv6 networks employ routing protocols to Some organizational IPv6 networks employ routing protocols to
dynamically maintain routing information. In such an environment, a dynamically maintain routing information. In such an environment, a
local attacker could become a passive listener of the routing local attacker could become a passive listener of the routing
protocol, to determine other valid subnets within that organization protocol, to determine other valid subnets/prefixes and some router
[V6-WORMS]. addresses within that organization [V6-WORMS].
11. Conclusions 11. Gleaning Information from IP Flow Information Export (IPFIX)
IPFIX [RFC7012] can aggregate the flows by source addresses, and
hence may be leveraged for obtaining a list of "active" IPv6
addresses. Additional discussion of IPFIX can be found in
Section 2.5.1.2 of [I-D.ietf-opsec-v6].
12. Obtaining Network Information with traceroute6
IPv6 traceroute [traceroute6] can be employed to find router
addresses and valid network prefixes.
13. Conclusions
In this document we have discussed issues around host-based scanning 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 of IPv6 networks. We have shown why a /64 host subnet may be more
vulnerable to address-based scanning that might intuitively be vulnerable to address-based scanning that might intuitively be
thought, and how an attacker might reduce the target search space thought, and how an attacker might reduce the target search space
when scanning. when scanning.
We have described a number of mitigations against host-based We have described a number of mitigations against host-based
scanning, including the replacement of traditional SLAAC with stable scanning, including the replacement of traditional SLAAC with stable
privacy-enhanced IIDs (which will require support from system privacy-enhanced IIDs (which will require support from system
skipping to change at page 23, line 39 skipping to change at page 24, line 5
While most early IPv6-enabled networks remain dual-stack, they are While most early IPv6-enabled networks remain dual-stack, they are
more likely to be scanned and attacked over IPv4 transport, and one more likely to be scanned and attacked over IPv4 transport, and one
may argue that the IPv6-specific considerations discussed here are may argue that the IPv6-specific considerations discussed here are
not of an immediate concern. However, an early IPv6 deployment not of an immediate concern. However, an early IPv6 deployment
within a dual-stack network may be seen by an attacker as a within a dual-stack network may be seen by an attacker as a
potentially "easier" target, if the implementation of security potentially "easier" target, if the implementation of security
policies are not as strict for IPv6 (for whatever reason). As and policies are not as strict for IPv6 (for whatever reason). As and
when IPv6-only networks become more common, the considerations in when IPv6-only networks become more common, the considerations in
this document will be of much greater importance. this document will be of much greater importance.
12. IANA Considerations 14. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
13. Security Considerations 15. Security Considerations
This document explores the topic of Network Reconnaissance in IPv6 This document explores the topic of Network Reconnaissance in IPv6
networks. It analyzes the feasibility of address-scan attacks in networks. It analyzes the feasibility of address-scan attacks in
IPv6 networks, and showing that the search space for such attacks is IPv6 networks, and showing that the search space for such attacks is
typically much smaller than the one traditionally assumed (64 bits). typically much smaller than the one traditionally assumed (64 bits).
Additionally, it explores a plethora of other network reconnaissance Additionally, it explores a plethora of other network reconnaissance
techniques, ranging from inspecting the IPv6 Network Cache of an techniques, ranging from inspecting the IPv6 Network Cache of an
attacker-controlled system, to gleaning information about IPv6 attacker-controlled system, to gleaning information about IPv6
addresses from public mailing-list archives or Peer-To-Peer (P2P) addresses from public mailing-list archives or Peer-To-Peer (P2P)
protocols. protocols.
We expect traditional address-scanning attacks to become more and We expect traditional address-scanning attacks to become more and
more elaborated (i.e., less "brute force"), and other network more elaborated (i.e., less "brute force"), and other network
reconnaissance techniques to be actively explored, as global reconnaissance techniques to be actively explored, as global
deployment of IPv6 increases and. more specifically, as more deployment of IPv6 increases and. more specifically, as more
IPv6-only devices are deployed. IPv6-only devices are deployed.
14. Acknowledgements 16. Acknowledgements
The authors would like to thank (in alphabetical order) Marc Heuse, The authors would like to thank (in alphabetical order) Marc Heuse,
Ray Hunter, Libor Polcak, Jan Schaumann, and Arturo Servin, for Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric
providing valuable comments on earlier versions of this document. 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 Part of the contents of this document are based on the results of the
project "Security Assessment of the Internet Protocol version 6 project "Security Assessment of the Internet Protocol version 6
(IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK
Centre for the Protection of National Infrastructure (CPNI). Centre for the Protection of National Infrastructure (CPNI).
Fernando Gont would like to thank the UK CPNI for their continued Fernando Gont would like to thank the UK CPNI for their continued
support. support.
15. References 17. References
15.1. Normative References 17.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, 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.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February Network Address Translations (NATs)", RFC 4380, February
2006. 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, February 2014.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
15.2. Informative References 17.2. Informative References
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, January Multicast Name Resolution (LLMNR)", RFC 4795, January
2007. 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
5157, March 2008. 5157, March 2008.
skipping to change at page 25, line 42 skipping to change at page 26, line 16
February 2013. February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[I-D.gont-6man-ipv6-smurf-amplifier] [I-D.gont-6man-ipv6-smurf-amplifier]
Gont, F. and W. Liu, "Security Implications of IPv6 Gont, F. and W. Liu, "Security Implications of IPv6
Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf-
amplifier-03 (work in progress), March 2013. amplifier-03 (work in progress), March 2013.
[I-D.ietf-6man-why64] [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", draft-ietf-6man-why64-01 (work in in IPv6 Addressing", RFC 7421, January 2015.
progress), May 2014.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will, Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-00 (work in progress), draft-ietf-6man-default-iids-01 (work in progress),
January 2014. October 2014.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-01 (work draft-ietf-6man-ipv6-address-generation-privacy-03 (work
in progress), February 2014. in progress), January 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-00 (work in progress),
October 2014.
[I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", draft-ietf-
opsec-v6-05 (work in progress), October 2014.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[V6-WORMS] [V6-WORMS]
Bellovin, S., Cheswick, B., and A. Keromytis, "Worm Bellovin, S., Cheswick, B., and A. Keromytis, "Worm
propagation strategies in an IPv6 Internet", ;login:, propagation strategies in an IPv6 Internet", ;login:,
pages 70-76, February 2006, pages 70-76, February 2006,
skipping to change at page 26, line 47 skipping to change at page 27, line 36
[VBox2011] [VBox2011]
VirtualBox, , "Oracle VM VirtualBox User Manual, version VirtualBox, , "Oracle VM VirtualBox User Manual, version
4.1.2", August 2011, <http://www.virtualbox.org>. 4.1.2", August 2011, <http://www.virtualbox.org>.
[vmesx2011] [vmesx2011]
vmware, , "Setting a static MAC address for a virtual vmware, , "Setting a static MAC address for a virtual
NIC", vmware Knowledge Base, August 2011, NIC", vmware Knowledge Base, August 2011,
<http://kb.vmware.com/selfservice/microsites/ <http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=219>. search.do?language=en_US&cmd=displayKC&externalId=219>.
[traceroute6]
FreeBSD, , "FreeBSD System Manager's Manual:
traceroute6(8) manual page", 2009,
<https://www.freebsd.org/cgi/man.cgi?query=traceroute6>.
[Ybema2010] [Ybema2010]
Ybema, I., "just seen my first IPv6 network abuse scan, is Ybema, I., "just seen my first IPv6 network abuse scan, is
this the start for more?", Post to the NANOG mailing-list, this the start for more?", Post to the NANOG mailing-list,
2010, <http://mailman.nanog.org/pipermail/ 2010, <http://mailman.nanog.org/pipermail/
nanog/2010-September/025049.html>. nanog/2010-September/025049.html>.
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, F., "Results of a Security Assessment of the Gont, F., "Results of a Security Assessment of the
Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Internet Protocol version 6 (IPv6)", DEEPSEC 2011
Conference, Vienna, Austria, November 2011, 2011, Conference, Vienna, Austria, November 2011, 2011,
 End of changes. 36 change blocks. 
79 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/