draft-ietf-opsec-ipv6-host-scanning-02.txt   draft-ietf-opsec-ipv6-host-scanning-03.txt 
Operational Security Capabilities for F. Gont opsec F. Gont
IP Network Infrastructure (opsec) Huawei Technologies Internet-Draft Huawei Technologies
Internet-Draft T. Chown Obsoletes: 5157 (if approved) T. Chown
Obsoletes: 5157 (if approved) University of Southampton Intended status: Informational University of Southampton
Intended status: Informational July 15, 2013 Expires: July 27, 2014 January 23, 2014
Expires: January 16, 2014
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-02 draft-ietf-opsec-ipv6-host-scanning-03
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. The standard /64 IPv6 subnets can (in theory) counterpart. The standard /64 IPv6 subnets can (in theory)
accommodate approximately 1.844 * 10^19 hosts, thus resulting in a accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
much lower host density (#hosts/#addresses) than is typical in IPv4 much lower host density (#hosts/#addresses) than is typical in IPv4
networks, where a site typically has 65,000 or less unique addresses. 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 As a result, it is widely assumed that it would take a tremendous
effort to perform address scanning attacks against IPv6 networks, and effort to perform address scanning attacks against IPv6 networks, and
therefore classic IPv6 address scanning attacks have been considered therefore brute-force IPv6 address scanning attacks have been
unfeasible. This document updates RFC 5157 by providing further considered unfeasible. This document updates RFC 5157 by providing
analysis on how traditional address scanning techniques apply to IPv6 further analysis on how traditional address scanning techniques apply
networks, and exploring some additional techniques that can be to IPv6 networks, and exploring some additional techniques that can
employed for IPv6 network reconnaissance. In doing so, this document be employed for IPv6 network reconnaissance. In doing so, this
formally obsoletes RFC 5157. document formally obsoletes RFC 5157.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 16, 2014. This Internet-Draft will expire on July 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 2. Requirements for the Applicability of Network Reconnaissance
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 . . . . . . . . . . . . . . 5
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . . 14 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 15 3.1.2. Dynamic Host Configuration Protocol version 6
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . . 15 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10
3.1.4. IPv6 Addresses Corresponding to Transition/Co-
existence Technologies . . . . . . . . . . . . . . . 12
3.1.5. IPv6 Address Assignment in Real-world Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 12
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 16
3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 16
3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 17
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 17
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . 18 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 18 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 18
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 18 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 19
4.3. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . . 18 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 19
4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 19
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 20
7. Application Participation . . . . . . . . . . . . . . . . . . 22 7. Application Participation . . . . . . . . . . . . . . . . . . 20
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 23 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 20
9. Inspection of System Configuration and Log Files . . . . . . . 24 9. Inspection of System Configuration and Log Files . . . . . . 21
10. Gleaning Information from Routing Protocols . . . . . . . . . 25 10. Gleaning Information from Routing Protocols . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 14.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Implementation of a full-fledged IPv6 Appendix A. Implementation of a full-fledged IPv6 address-
address-scanning tool . . . . . . . . . . . . . . . . 32 scanning tool . . . . . . . . . . . . . . . . . . . 25
A.1. Host-probing considerations . . . . . . . . . . . . . . . 32 A.1. Host-probing considerations . . . . . . . . . . . . . . . 25
A.2. Implementation of an IPv6 local address-scanning tool . . 33 A.2. Implementation of an IPv6 local address-scanning tool . . 27
A.3. Implementation of a IPv6 remote address-scanning tool . . 34 A.3. Implementation of a IPv6 remote address-scanning tool . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 addresses of these changes is the reduced host density (the number of addresses
divided by the number of hosts) of typical IPv6 subnetworks: with divided by the number of hosts) of typical IPv6 subnetworks: with
default IPv6 subnets of /64, each subnet comprises more than 1.844 * default IPv6 subnets of /64, each subnet comprises more than 1.844 *
skipping to change at page 4, line 19 skipping to change at page 5, line 6
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 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 |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Remote Address scans (Section 3.2) | No | No | | Remote Address scans (Section 3.2) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| DNS Advertised Hosts (Section 4.1) | No | No | | DNS Advertised Hosts (Section 4.1) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| DNS Zone Transfers (Section 4.2) | No | No | | DNS Zone Transfers (Section 4.2) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| DNS reverse mappings (Section 4.3) | No | No | | DNS reverse mappings (Section 4.4) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Public archives (Section 6) | No | No | | Public archives (Section 6) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Application Participation (Section 7) | No | No | | Application Participation (Section 7) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| 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) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
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
skipping to change at page 8, line 9 skipping to change at page 8, line 42
It is important to note that "privacy addresses" are generated in It is important to note that "privacy addresses" are generated in
addition to traditional SLAAC addresses (i.e., based on IEEE addition to traditional SLAAC addresses (i.e., based on IEEE
identifiers): traditional SLAAC addresses are employed for incoming identifiers): traditional SLAAC addresses are employed for incoming
(i.e. server-like) communications, while "privacy addresses" are (i.e. server-like) communications, while "privacy addresses" are
employed for outgoing (i.e., client-like) communications. This means employed for outgoing (i.e., client-like) communications. This means
that implementation/use of "privacy addresses" does not prevent an that implementation/use of "privacy addresses" does not prevent an
attacker from leveraging the predictability of traditional SLAAC attacker from leveraging the predictability of traditional SLAAC
addresses, since "privacy addresses" are generated in addition to addresses, since "privacy addresses" are generated in addition to
(rather than in replacement of) the traditional SLAAC addresses (rather than in replacement of) the traditional SLAAC addresses
derived from e.g. IEEE identifiers. derived from e.g. IEEE identifiers.
The benefit that privacy addresses offer in this context is that they The benefit that privacy addresses offer in this context is that they
reduce the exposure of the SLAAC address to any third parties that reduce the exposure of the SLAAC address to any third parties that
may observe that address in use. But, in the absence of firewall may observe that address in use. But, in the absence of firewall
protection for the host, the SLAAC address remains liable to be protection for the host, the SLAAC address remains liable to be
scanned from offsite. scanned from offsite.
3.1.1.3. Randomized Stable Interface Identifiers 3.1.1.3. Randomized Stable Interface Identifiers
In order to mitigate the security implications arising from the In order to mitigate the security implications arising from the
skipping to change at page 9, line 23 skipping to change at page 10, line 10
DHCPv6 can be employed as a stateful address configuration mechanism, DHCPv6 can be employed as a stateful address configuration mechanism,
in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6
hosts. As with the IPv4 counterpart, addresses are assigned hosts. As with the IPv4 counterpart, addresses are assigned
according to a configuration-defined address range and policy, with according to a configuration-defined address range and policy, with
some DHCPv6 servers assigned addresses sequentially, from a specific some DHCPv6 servers assigned addresses sequentially, from a specific
range. In such cases, addresses tend to be predictable. 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 - 2001: (sequentially) assign addresses from the range 2001:db8::1 -
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.
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
skipping to change at page 9, line 51 skipping to change at page 10, line 38
(i.e., ease of remembering) they tend to select addresses with one of (i.e., ease of remembering) they tend to select addresses with one of
the following patterns: the following patterns:
o "low-byte" addresses: in which most of the bytes of the IID are o "low-byte" addresses: in which most of the bytes of the IID are
set to 0 (except for the least significant byte). set to 0 (except for the least significant byte).
o IPv4-based addresses: in which the IID embeds the IPv4 address of o IPv4-based addresses: in which the IID embeds the IPv4 address of
the network interface (as in 2001:db8::192.0.2.1) the network interface (as in 2001:db8::192.0.2.1)
o "service port" addresses: in which the IID embeds the TCP/UDP o "service port" addresses: in which the IID embeds the TCP/UDP
service port of the main service running on that node (as in 2001: service port of the main service running on that node (as in
2001:db8::80 or 2001:db8::25)
db8::80 or 2001:db8::25)
o wordy addresses: which encode words (as in 2001:db8::dead:beef) o wordy addresses: which encode words (as in 2001:db8::dead:beef)
Each of these patterns is discussed in detail in the following Each of these patterns is discussed in detail in the following
subsections. subsections.
3.1.3.1. Low-byte Addresses 3.1.3.1. Low-byte Addresses
The most common form of low-byte addresses is that in which all the 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 the bytes of the IID (except the least significant bytes) are set to
skipping to change at page 10, line 35 skipping to change at page 11, line 21
IPv6 address that varies from one address to another. IPv6 address that varies from one address to another.
In the worst-case scenario, the search space for this pattern is 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**24 (although most systems can be found by searching 2**16 or even
2**8 addresses). 2**8 addresses).
3.1.3.2. IPv4-based Addresses 3.1.3.2. IPv4-based Addresses
The most common form of these addresses is that in which an IPv4 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 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: (usually as a result of the notation of addresses in the form
db8::192.0.2.1). However, it is also common for administrators to 2001:db8::192.0.2.1). However, it is also common for administrators
encode one byte of the IPv4 address in each of the 16-bit words of 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). the IID (as in e.g. 2001:db8::192:0:2:1).
For obvious reasons, the search space for addresses following this For obvious reasons, the search space for addresses following this
pattern is that of the corresponding IPv4 prefix (or twice the size 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 of that search space if both forms of "IPv4-based addresses" are to
be searched). be searched).
3.1.3.3. Service-port Addresses 3.1.3.3. Service-port Addresses
Address following this pattern include the service port, e.g., 80 for Address following this pattern include the service port, e.g., 80 for
skipping to change at page 12, line 8 skipping to change at page 13, line 8
Table 2, Table 3 and Table 4 provide a summary of the results Table 2, Table 3 and Table 4 provide a summary of the results
obtained by [Gont-LACSEC2013] for web servers, nameservers, and obtained by [Gont-LACSEC2013] for web servers, nameservers, and
mailservers, resectively. Table 5 provides a rough summary of the mailservers, resectively. Table 5 provides a rough summary of the
results obtained by [Malone2008] for IPv6 routers. Table 6 provides results obtained by [Malone2008] for IPv6 routers. Table 6 provides
a summary of the results obtained by [Ford2013] for clients. a summary of the results obtained by [Ford2013] for clients.
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 1.44% | | IEEE-based | 1.44% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 25.41% | | Embedded-IPv4 | 25.41% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 3.06% | | Embedded-Port | 3.06% |
+---------------+------------+ +---------------+------------+
| ISATAP | 0% | | ISATAP | 0% |
+---------------+------------+ +---------------+------------+
| Low-byte | 56.88% | | Low-byte | 56.88% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 6.97% | | Byte-pattern | 6.97% |
+---------------+------------+ +---------------+------------+
| Randomized | 6.24% | | Randomized | 6.24% |
+---------------+------------+ +---------------+------------+
Table 2: Measured webserver addresses Table 2: Measured webserver addresses
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 0.67% | | IEEE-based | 0.67% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 22.11% | | Embedded-IPv4 | 22.11% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 6.48% | | Embedded-Port | 6.48% |
+---------------+------------+ +---------------+------------+
| ISATAP | 0% | | ISATAP | 0% |
+---------------+------------+ +---------------+------------+
| Low-byte | 56.58% | | Low-byte | 56.58% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 11.07% | | Byte-pattern | 11.07% |
+---------------+------------+ +---------------+------------+
| Randomized | 3.09% | | Randomized | 3.09% |
+---------------+------------+ +---------------+------------+
Table 3: Measured nameserver addresses Table 3: Measured nameserver addresses
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 0.48% | | IEEE-based | 0.48% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 4.02% | | Embedded-IPv4 | 4.02% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 1.07% | | Embedded-Port | 1.07% |
+---------------+------------+ +---------------+------------+
| ISATAP | 0% | | ISATAP | 0% |
+---------------+------------+ +---------------+------------+
| Low-byte | 92.65% | | Low-byte | 92.65% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 1.20% | | Byte-pattern | 1.20% |
+---------------+------------+ +---------------+------------+
| Randomized | 0.59% | | Randomized | 0.59% |
+---------------+------------+ +---------------+------------+
Table 4: Measured mailserver addresses Table 4: Measured mailserver addresses
+--------------+------------+ +--------------+------------+
| Address type | Percentage | | Address type | Percentage |
+--------------+------------+ +--------------+------------+
| Low-byte | 70% | | Low-byte | 70% |
+--------------+------------+ +--------------+------------+
| IPv4-based | 5% | | IPv4-based | 5% |
+--------------+------------+ +--------------+------------+
| SLAAC | 1% | | SLAAC | 1% |
+--------------+------------+ +--------------+------------+
| Wordy | <1% | | Wordy | <1% |
+--------------+------------+ +--------------+------------+
| Randomized | <1% | | Randomized | <1% |
+--------------+------------+ +--------------+------------+
| Teredo | <1% | | Teredo | <1% |
+--------------+------------+ +--------------+------------+
| Other | <1% | | Other | <1% |
+--------------+------------+ +--------------+------------+
Table 5: Measured router addresses Table 5: Measured router addresses
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 7.72% | | IEEE-based | 7.72% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 14.31% | | Embedded-IPv4 | 14.31% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 0.21% | | Embedded-Port | 0.21% |
+---------------+------------+ +---------------+------------+
| ISATAP | 1.06% | | ISATAP | 1.06% |
+---------------+------------+ +---------------+------------+
| Randomized | 69.73% | | Randomized | 69.73% |
+---------------+------------+ +---------------+------------+
| Low-byte | 6.23% | | Low-byte | 6.23% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 0.74% | | Byte-pattern | 0.74% |
+---------------+------------+ +---------------+------------+
Table 6: Measured client addresses Table 6: Measured client addresses
It should be clear from these measurements that a very high It should be clear from these measurements that a very high
percentage of host and router addresses follow very specific percentage of host and router addresses follow very specific
patterns. patterns.
Table 6 shows that while around 70% of clients observed in this Table 6 shows that while around 70% of clients observed in this
measurement appear to be using privacy addresses, there are still a measurement appear to be using privacy addresses, there are still a
skipping to change at page 18, line 9 skipping to change at page 18, line 50
network reconnaissance vectors. Therefore, even if address-scanning network reconnaissance vectors. Therefore, even if address-scanning
vectors are mitigated, an attacker could still rely on e.g. protocols vectors are mitigated, an attacker could still rely on e.g. protocols
employed for the so-called "opportunistic networking" (such as mDNS employed for the so-called "opportunistic networking" (such as mDNS
[RFC6762]), or eventually rely on network snooping as last resort for [RFC6762]), or eventually rely on network snooping as last resort for
network reconnaissance. network reconnaissance.
4. Leveraging the Domain Name System (DNS) for Network Reconnaissance 4. Leveraging the Domain Name System (DNS) for Network Reconnaissance
4.1. DNS Advertised Hosts 4.1. DNS Advertised Hosts
Any systems that are "published" in the DNS, e.g. MX mail relays, or Any systems that are "published" in the DNS, e.g. MX mail relays, or
web servers, will remain open to probing from the very fact that web servers, will remain open to probing from the very fact that
their IPv6 addresses are publicly available. It is worth noting that their IPv6 addresses are publicly available. It is worth noting that
where the addresses used at a site follow specific patterns, where the addresses used at a site follow specific patterns,
publishing just one address may lead to a threat upon the other publishing just one address may lead to a threat upon the other
hosts. hosts.
Additionally, we note that publication of IPv6 addresses in the DNS Additionally, we note that publication of IPv6 addresses in the DNS
should not discourage the elimination of IPv6 address patterns: if should not discourage the elimination of IPv6 address patterns: if
any address patterns are eliminated from addresses published in the any address patterns are eliminated from addresses published in the
DNS, an attacker may have to rely on performing dictionary-based DNS DNS, an attacker may have to rely on performing dictionary-based DNS
skipping to change at page 18, line 31 skipping to change at page 19, line 23
generally less reliable and more time/traffic consuming than mapping generally less reliable and more time/traffic consuming than mapping
nodes with predictable IPv6 addresses). nodes with predictable IPv6 addresses).
4.2. DNS Zone Transfers 4.2. DNS Zone Transfers
A DNS zone transfer can readily provide information about potential A DNS zone transfer can readily provide information about potential
attack targets. Restricting zone transfers is thus probably more attack targets. Restricting zone transfers is thus probably more
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.2.1. DNS Brute Forcing 4.3. DNS Brute Forcing
Attakers may employ DNS brute-forcing techniques by testing for the Attakers 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.3. DNS Reverse Mappings 4.4. DNS Reverse Mappings
An interesting technique that employs DNS reverse mappings for An interesting technique that employs DNS reverse mappings for
network reconnaissance has been recently disclosed [van-Dijk]. network reconnaissance has been recently disclosed [van-Dijk].
Essentially, the attacker walks through the "ip6.arpa" zone looking Essentially, the attacker walks through the "ip6.arpa" zone looking
up PTR records, in the hopes of learning the IPv6 addresses of hosts up PTR records, in the hopes of learning the IPv6 addresses of hosts
in a given target network (assuming that the reverse mappings have in a given target network (assuming that the reverse mappings have
been configured, of course). What is most interesting about this been configured, of course). What is most interesting about this
technique is that it can greatly reduce the IPv6 address search technique is that it 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 "2001: a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for
db8:80:/32"), issuing queries for PTR records corresponding to the "2001:db8:80::/32"), issuing queries for PTR records corresponding to
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
contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this
technique allows for a tremendous reduction in the "IPv6 address" technique allows for a tremendous reduction in the "IPv6 address"
search space. search space.
5. Leveraging Local Name Resolution and Service Discovery Services 5. Leveraging Local Name Resolution and Service Discovery Services
skipping to change at page 27, line 20 skipping to change at page 22, line 8
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 IPv6- deployment of IPv6 increases and. more specifically, as more
only devices are deployed. IPv6-only devices are deployed.
13. Acknowledgements 13. 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, and Arturo Servin, for
providing valuable comments on earlier versions of this document. 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
skipping to change at page 29, line 21 skipping to change at page 22, line 40
[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.
[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, Network Address Translations (NATs)", RFC 4380, February
February 2006. 2006.
[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, Multicast Name Resolution (LLMNR)", RFC 4795, January
January 2007. 2007.
[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.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
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.ietf-6man-stable-privacy-addresses] [I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A method for Generating Stable Privacy-Enhanced Gont, F., "A Method for Generating Semantically Opaque
Addresses with IPv6 Stateless Address Autoconfiguration Interface Identifiers with IPv6 Stateless Address
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-10 Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
(work in progress), June 2013. privacy-addresses-16 (work in progress), December 2013.
14.2. Informative References 14.2. Informative References
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
RFC 5157, March 2008. 5157, March 2008.
[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", Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf-
draft-gont-6man-ipv6-smurf-amplifier-03 (work in amplifier-03 (work in progress), March 2013.
progress), March 2013.
[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, <https://www.cs.columbia.edu/
<https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>. ~smb/papers/v6worms.pdf>.
[Malone2008] [Malone2008]
Malone, D., "Observations of IPv6 Addresses", Passive and Malone, D., "Observations of IPv6 Addresses", Passive and
Active Measurement Conference (PAM 2008, LNCS 4979), Active Measurement Conference (PAM 2008, LNCS 4979), April
April 2008, 2008,
<http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>. <http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.
[mdns-scan] [mdns-scan]
Poettering, L., "mdns-scan(1) manual page", 2012, <http:// Poettering, L., "mdns-scan(1) manual page", 2012,
manpages.ubuntu.com/manpages/precise/man1/ <http://manpages.ubuntu.com/manpages/precise/man1/
mdns-scan.1.html>. mdns-scan.1.html>.
[nmap2012] [nmap2012]
Fyodor, "nmap - Network exploration tool and security / Fyodor, , "nmap - Network exploration tool and security /
port scanner", 2012, <http://insecure.org>. port scanner", 2012, <http://insecure.org>.
[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 NIC", vmware, , "Setting a static MAC address for a virtual
vmware Knowledge Base, August 2011, <http:// NIC", vmware Knowledge Base, August 2011,
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>.
[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- this the start for more?", Post to the NANOG mailing-list,
list, 2010, <http://mailman.nanog.org/pipermail/nanog/ 2010, <http://mailman.nanog.org/pipermail/nanog/
2010-September/025049.html>. 2010-September/025049.html>.
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, "Results of a Security Assessment of the Internet Gont, F., "Results of a Security Assessment of the
Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Internet Protocol version 6 (IPv6)", DEEPSEC 2011
Vienna, Austria, November 2011, <http:// Conference, Vienna, Austria, November 2011, 2011,
www.si6networks.com/presentations/deepsec2011/ <http://www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013] [Gont-LACSEC2013]
Gont, "IPv6 Network Reconnaissance: Theory & Practice", Gont, F., "IPv6 Network Reconnaissance: Theory &
LACSEC 2013 Conference, Medellin, Colombia, May 2013, Practice", LACSEC 2013 Conference, Medellin, Colombia, May
<http://www.si6networks.com/presentations/lacnic19/ 2013, 2013, <http://www.si6networks.com/presentations/
lacnic19/
lacsec2013-fgont-ipv6-network-reconnaissance.pdf>. lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[Ford2013] [Ford2013]
Ford, "IPv6 Address Analysis - Privacy In, Transition Ford, M., "IPv6 Address Analysis - Privacy In, Transition
Out", 2013, <http://www.internetsociety.org/blog/2013/05/ Out", 2013, <http://www.internetsociety.org/blog/2013/05/
ipv6-address-analysis-privacy-transition-out>. ipv6-address-analysis-privacy-transition-out>.
[THC-IPV6] [THC-IPV6]
"THC-IPV6", <http://www.thc.org/thc-ipv6/>. "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
[IPv6-Toolkit] [IPv6-Toolkit]
"SI6 Networks' IPv6 Toolkit", "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[BitTorrent] [BitTorrent]
"BitTorrent", <http://en.wikipedia.org/wiki/BitTorrent>. "BitTorrent", <http://en.wikipedia.org/wiki/BitTorrent>.
[van-Dijk] [van-Dijk]
van Dijk, P., "Finding v6 hosts by efficiently mapping van Dijk, P., "Finding v6 hosts by efficiently mapping
ip6.arpa", <http://7bits.nl/blog/2012/03/26/ ip6.arpa", 2012, <http://7bits.nl/blog/2012/03/26/
finding-v6-hosts-by-efficiently-mapping-ip6-arpa>. finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
Appendix A. Implementation of a full-fledged IPv6 address-scanning tool Appendix A. Implementation of a full-fledged IPv6 address-scanning tool
This section describes the implementation of a full-fledged IPv6 This section describes the implementation of a full-fledged IPv6
address scanning tool. Appendix A.1 discusses the selection of host address scanning tool. Appendix A.1 discusses the selection of host
probes. Appendix A.2 describes the implementation of an IPv6 address probes. Appendix A.2 describes the implementation of an IPv6 address
scanner for local area networks. Appendix A.3 outlines ongoing work scanner for local area networks. Appendix A.3 outlines ongoing work
on the implementation of a general (i.e., non-local) IPv6 host on the implementation of a general (i.e., non-local) IPv6 host
scanner. scanner.
skipping to change at page 34, line 16 skipping to change at page 27, line 28
multicast address (ff02::1) is sent with each of the addresses multicast address (ff02::1) is sent with each of the addresses
"configured" in the previous step. Because of the different "configured" in the previous step. Because of the different
Source Addresses, each probe causes the victim nodes to use Source Addresses, each probe causes the victim nodes to use
different Source Addresses for the response packets (this allows different Source Addresses for the response packets (this allows
the tool to learn virtually all the addresses in use in the local the tool to learn virtually all the addresses in use in the local
network segment). network segment).
3. The same procedure of the previous bullet is performed, but this 3. The same procedure of the previous bullet is performed, but this
time with ICMPv6 packets that contain an unrecognized option of time with ICMPv6 packets that contain an unrecognized option of
type 10xxxxxx, such that ICMPv6 Parameter Problem error messages type 10xxxxxx, such that ICMPv6 Parameter Problem error messages
are elicited. This allows the tool to discover e.g. Windows are elicited. This allows the tool to discover e.g. Windows
nodes, which otherwise do not respond to multicasted ICMPv6 Echo nodes, which otherwise do not respond to multicasted ICMPv6 Echo
Request messages. Request messages.
4. Each time a new "alive" address is discovered, the corresponding 4. Each time a new "alive" address is discovered, the corresponding
Interface-ID is combined with all the local prefixes, and the Interface-ID is combined with all the local prefixes, and the
resulting addresses are probed (with unicasted packets). This resulting addresses are probed (with unicasted packets). This
can help to discover other addresses in use on the local network can help to discover other addresses in use on the local network
segment, since the same Interface ID is typically used with all segment, since the same Interface ID is typically used with all
the available prefixes for the local network. the available prefixes for the local network.
skipping to change at page 36, line 20 skipping to change at page 28, line 47
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
Tim Chown Tim Chown
University of Southampton University of Southampton
Highfield Highfield
Southampton, Hampshire SO17 1BJ Southampton , Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
 End of changes. 70 change blocks. 
137 lines changed or deleted 146 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/