draft-ietf-opsec-ipv6-host-scanning-00.txt   draft-ietf-opsec-ipv6-host-scanning-01.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) Huawei Technologies IP Network Infrastructure (opsec) Huawei Technologies
Internet-Draft T. Chown Internet-Draft T. Chown
Obsoletes: 5157 (if approved) University of Southampton Obsoletes: 5157 (if approved) University of Southampton
Intended status: Informational December 12, 2012 Intended status: Informational April 30, 2013
Expires: June 15, 2013 Expires: November 1, 2013
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-00 draft-ietf-opsec-ipv6-host-scanning-01
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 their IPv4 much lower host density (#hosts/#addresses) than their IPv4
counterparts. As a result, it is widely assumed that it would take a counterparts. As a result, it is widely assumed that it would take a
tremendous effort to perform address scanning attacks against IPv6 tremendous effort to perform address scanning attacks against IPv6
networks, and therefore IPv6 address scanning attacks have long been networks, and therefore IPv6 address scanning attacks have long been
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 June 15, 2013. This Internet-Draft will expire on November 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 Techniques . . . . . . . . . . . . . . . . . . 4 Reconnaissance 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 . . . . . . . . . 11 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . . 12
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 11 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 12
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . . 12 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . . 13
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 14
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . 15 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 15 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 16
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 15 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 16
4.3. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . . 15 4.3. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . . 16
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 18 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 19
7. Application Participation . . . . . . . . . . . . . . . . . . 19 7. Application Participation . . . . . . . . . . . . . . . . . . 20
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 20 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 21
9. Inspection of System Configuration and Log Files . . . . . . . 21 9. Inspection of System Configuration and Log Files . . . . . . . 22
10. Gleaning Information from Routing Protocols . . . . . . . . . 22 10. Gleaning Information from Routing Protocols . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Implementation of a full-fledged IPv6 Appendix A. Implementation of a full-fledged IPv6
address-scanning tool . . . . . . . . . . . . . . . . 29 address-scanning tool . . . . . . . . . . . . . . . . 30
A.1. Host-probing considerations . . . . . . . . . . . . . . . 29 A.1. Host-probing considerations . . . . . . . . . . . . . . . 30
A.2. Implementation of an IPv6 local address-scanning tool . . 30 A.2. Implementation of an IPv6 local address-scanning tool . . 31
A.3. Implementation of a IPv6 remote address-scanning tool . . 31 A.3. Implementation of a IPv6 remote address-scanning tool . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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 such changes is the reduced host density (Nr. of addresses/Nr. of of such changes is the reduced host density (Nr. of addresses/Nr. of
hosts) of typical IPv6 subnetworks: with default IPv6 subnets of /64, hosts) of typical IPv6 subnetworks: with default IPv6 subnets of /64,
each subnet comprises more than 1.844 * 10^19 addresses; however, the each subnet comprises more than 1.844 * 10^19 addresses; however, the
skipping to change at page 9, line 13 skipping to change at page 9, line 13
(sequentially) assign addresses from the range 2001:db8::1 - 2001: (sequentially) assign addresses from the range 2001:db8::1 - 2001:
db8::100. 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. be reduced from the original 64 bits, to 8 or 16 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. routers do not employ automatic address configuration) but also for
servers (since having a stable address that does not depend on the
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
any value in the range 1 - 264 range, for the sake of simplicity any value in the range 1 - 264 range, for the sake of simplicity
(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 all bytes of the IID (except the o "low-byte" addresses: in which most of the bytes of the IID are
lowest one) are set to 0. set to 0 (except for the least significant byte).
o IPv4-based addresses: in which the IID encodes 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.168.1.1) the network interface (as in 2001:db8::192.0.2.1)
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:
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)
Clearly, the first two patterns reduce the search space from the Each of these patterns is discussed in detail in the following
original 64 bits to roughly 8 bits (assuming the IPv4 address range subsections.
is known for the case of "IPv4-based" addresses). On the other hand,
the search space for IPv6 wordy-addresses is probably larger and more 3.1.3.1. Low-byte Addresses
complex, but still greatly reduced when compared to the original 64-
bit search space. The most common form of low-byte addresses is that in which all the
the bytes of the IID (except the least significant bytes) are set to
zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also
common to find similar addresses in which the two lowest order 16-bit
words are set to small numbers (as in 2001::db8::1:10,
2001:db8::2:10, etc.). Yet it is not uncommon to find IPv6 addresses
in which the second lowest-order 16-bit word is set to a small value
in the range 0-255, while the lowest-order 16-bit word varies in the
range 0-65535. It should be noted that all of these address patterns
are generally referred to as "low-byte addresses", even when,
strictly speaking, it is not not only the lowest-order byte of the
IPv6 address that varies from one address to another.
In the worst-case scenario, the search space for this pattern is
2**24 (although most systems can be found by searching 2**16 or even
2**8 addresses).
3.1.3.2. IPv4-based Addresses
The most common form of these addresses is that in which an IPv4
address is encoded in the lowest-order 32 bits of the IPv6 address
(usually as a result of the notation of addresses in the form 2001:
db8::192.0.2.1). However, it is also common for administrators to
encode one byte of the IPv4 address in each of the 16-bit words of
the IID (as in e.g. 2001:db8::192:0:2:1).
For obvious reasons, the search space for addresses following this
pattern is that of the corresponding IPv4 prefix (or twice the size
of that search space if both forms of "IPv4-based addresses" are to
be searched).
3.1.3.3. Service-port Addresses
Address following this pattern include the service port 8e.g., 80 for
HTTP) in the lowest-order byte of the IID, and set the rest of the
IID to zero. There are a number of variants for this address
pattern:
o The lowest-order 16-bit word may contain the service port, and the
second lowest-order 16-bit word may be set to a number in the
range 0-255 (as in e.g. 2001:db8::1:80).
o The lowest-order 16-bit word may be set to a value in the range
0-255, while the second lowest-order 16-bit word may contain the
service port (as in e.g. 2001:db8::80:1).
o The service port itself might be encoded in decimal or in
hexadecimal notation (e.g., an address embedding the HTTP port
might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding
the service port as a decimal number being more common.
Considering a maximum of 20 popular service ports, the search space
for addresses following in this pattern is, in the worst-case
scenario, 20 * 2**10.
3.1.3.4. Wordy Addresses
Since IPv6 address notation allows for a number of hexadecimal
digits, it is not difficult to encode words into IPv6 addresses (as
in, e.g., 2001:db8::dead:beef).
Addresses following this pattern are likely to be explored by means
of "dictionary attacks", and therefore computing the corresponding
search-space is not straight-forward.
3.1.4. IPv6 Addresses Corresponding to Transition/Co-existence 3.1.4. IPv6 Addresses Corresponding to Transition/Co-existence
Technologies Technologies
Some transition/co-existence technologies might be leveraged to Some transition/co-existence technologies might be leveraged to
reduce the target search space of remote address-scanning attacks, reduce the target search space of remote address-scanning attacks,
since they specify how the corresponding IPv6 address must be since they specify how the corresponding IPv6 address must be
generated. For example, in the case of Teredo [RFC4380], the 64-bit generated. For example, in the case of Teredo [RFC4380], the 64-bit
interface identifier is generated from the IPv4 address observed at a interface identifier is generated from the IPv4 address observed at a
Teredo server along with a UDP port number. Teredo server along with a UDP port number.
skipping to change at page 12, line 23 skipping to change at page 13, line 47
3.4.1. Remote IPv6 Network Scanners 3.4.1. Remote IPv6 Network Scanners
IPv4 address scanning tools have traditionally carried out their task IPv4 address scanning tools have traditionally carried out their task
for probing an entire address range (usually the entire range of a for probing an entire address range (usually the entire range of a
target subnetwork). One might argue that the reason for which we target subnetwork). One might argue that the reason for which we
have been able to get away with such somewhat "rudimentary" have been able to get away with such somewhat "rudimentary"
techniques is that the scale of the "problem" is so small in the IPv4 techniques is that the scale of the "problem" is so small in the IPv4
world, that a "brute-force" attack is "good enough". However, the world, that a "brute-force" attack is "good enough". However, the
scale of the "address scanning" problem is so large in IPv6, that scale of the "address scanning" problem is so large in IPv6, that
attackers must be very creative to be "good enough". attackers must be very creative to be "good enough". Simply sweeping
an entire /64 IPv6 subnet would just not be feasible.
Simply sweeping an entire /64 IPv6 subnet would just not be feasible.
For instance, that is one of the reasons for which address scanning
tools such as nmap [nmap2012] do not even support sweeping an IPv6
address range.
The nmap(1) manual page states "IPv6 addresses can only be Many address scanning tools such as nmap [nmap2012] do not even
specified by their fully qualified IPv6 address or hostname. CIDR support sweeping an IPv6 address range. On the other hand, the
and octet ranges aren't supported for IPv6 because they are rarely alive6 tool from [THC-IPV6] supports sweeping address ranges, thus
useful. being able to leverage some patters found in IPv6 addresses, such as
the incremental addresses resulting from some DHCPv6 setups.
Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address
ranges, and can also leverage all the address patterns described in
Section 3.1 of this document.
On the other hand, the alive6 tool from [THC-IPV6] supports Clearly, a limitation of many of the currently-available tools for
sweeping address ranges, thus being able to leverage some patters IPv6 address scanning is that they lack of an "heuristics engine"
fond in IPv6 addresses, such as the incremental addresses that can help reduce the search space, such that the problem of IPv6
resulting from some DHCPv6 setups. address scanning becomes tractable.
The most "advanced" IPv6 scanning technique that has been found in The most "advanced" IPv6 scanning technique that has been found in
the wild is that reported in [Ybema2010], in which the attacker the wild (and publicly reported) is described in [Ybema2010] (the
seemed to be scanning specific IPv6 addresses based on specific attacker seemed to be scanning specific IPv6 addresses based on some
patterns. However, the aforementioned attempt probably still falls specific patterns). However, the aforementioned attempt probably
into the category of "rudimentary". still falls into the category of "rudimentary".
Clearly, a limitation of most currently-available tools is that they
lack of an "heuristics engine" that can help reduce the search space,
such that the problem of IPv6 address scanning becomes tractable.
However, we expect that this situation will change in the short term.
3.4.2. Local IPv6 Network Scanners 3.4.2. Local IPv6 Network Scanners
There are a variety of publicly-available local IPv6 network There are a variety of publicly-available local IPv6 network
scanners: scanners:
Current versions of nmap [nmap2012] implement this functionality Current versions of nmap [nmap2012] implement this functionality
THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool that THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool that
implements this functionality implements this functionality
skipping to change at page 14, line 16 skipping to change at page 15, line 34
packets never elicit ICMPv6 error messages (even if they contain packets never elicit ICMPv6 error messages (even if they contain
unsupported options of type 10xxxxxx). unsupported options of type 10xxxxxx).
[I-D.gont-6man-ipv6-smurf-amplifier] proposes such update to the [I-D.gont-6man-ipv6-smurf-amplifier] proposes such update to the
IPv6 specifications. IPv6 specifications.
In any case, when it comes to local networks, there are a variety of In any case, when it comes to local networks, there are a variety of
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
[draft-cheshire-dnsext-multicastdns]), or eventually rely on network [RFC6762]), or eventually rely on network snooping as last resort for
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
skipping to change at page 17, line 8 skipping to change at page 18, line 8
"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
A number of protocols allow for unmanaged local name resolution and A number of protocols allow for unmanaged local name resolution and
service. For example, multicast DNS (mDNS) service. For example, multicast DNS (mDNS) [RFC6762] and DNS Service
[draft-cheshire-dnsext-multicastdns] and DNS Service Discovery Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution
(DNS-SD) [I-D.cheshire-dnsext-dns-sd], or Link-Local Multicast Name (LLMNR) [RFC4795], are examples of such protocols.
Resolution (LLNR) [RFC4795], are examples of such protocols.
Besides the Graphical User Interfaces (GUIs) included in products Besides the Graphical User Interfaces (GUIs) included in products
supporting such protocols, command-line tools such as mdns-scan supporting such protocols, command-line tools such as mdns-scan
[mdns-scan] and mzclient can help discover IPv6 hosts employing [mdns-scan] and mzclient can help discover IPv6 hosts employing
mDNS/DNS-SD. mDNS/DNS-SD.
6. Public Archives 6. Public Archives
Public mailing-list archives or Usenet news messages archives may Public mailing-list archives or Usenet news messages archives may
prove a useful channel for an attacker, since hostnames and/or IPv6 prove a useful channel for an attacker, since hostnames and/or IPv6
skipping to change at page 25, line 7 skipping to change at page 26, line 7
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 IPv6-
only devices are deployed. only devices are deployed.
13. Acknowledgements 13. Acknowledgements
The author 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
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.
skipping to change at page 26, line 42 skipping to change at page 27, line 42
[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.
[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 Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-01 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-06
(work in progress), October 2012. (work in progress), April 2013.
[draft-cheshire-dnsext-multicastdns] [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
Cheshire, S. and M. Krochmal, "Multicast DNS Trees in February 2013.
PIM-SM", December 2011.
[I-D.cheshire-dnsext-dns-sd] [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
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.
[I-D.gont-6man-ipv6-smurf-amplifier] [I-D.gont-6man-ipv6-smurf-amplifier]
Gont, F., "Security Implications of IPv6 options of Type Gont, F. and W. Liu, "Security Implications of IPv6
10xxxxxx", draft-gont-6man-ipv6-smurf-amplifier-00 (work Options of Type 10xxxxxx",
in progress), December 2011. draft-gont-6man-ipv6-smurf-amplifier-03 (work in
progress), March 2013.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008. RFC 5157, March 2008.
[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]
skipping to change at page 28, line 22 skipping to change at page 29, line 23
Gont, "Results of a Security Assessment of the Internet Gont, "Results of a Security Assessment of the Internet
Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Protocol version 6 (IPv6)", DEEPSEC 2011 Conference,
Vienna, Austria, November 2011, <http:// Vienna, Austria, November 2011, <http://
www.si6networks.com/presentations/deepsec2011/ www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
[THC-IPV6] [THC-IPV6]
"THC-IPV6", <http://www.thc.org/thc-ipv6/>. "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
[IPv6-Toolkit] [IPv6-Toolkit]
"IPv6 Toolkit", "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[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", <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
skipping to change at page 29, line 30 skipping to change at page 30, line 30
block or rate-limit some specific packet types. For example, it is block or rate-limit some specific packet types. For example, it is
usual for host and router implementations to rate-limit ICMPv6 error usual for host and router implementations to rate-limit ICMPv6 error
traffic. Additionally, some firewalls might be configured to block traffic. Additionally, some firewalls might be configured to block
or rate-limit incoming ICMPv6 echo request packets. or rate-limit incoming ICMPv6 echo request packets.
As noted earlier in this document, Windows systems simply do not As noted earlier in this document, Windows systems simply do not
respond to ICMPv6 echo requests sent to multicast IPv6 addresses. respond to ICMPv6 echo requests sent to multicast IPv6 addresses.
Among the possible probe types are: Among the possible probe types are:
o TCP segments meant to elicit SYN/ACK or RST segments, o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies),
o UDP segments meant to elicit a UDP application response or an o TCP SYN segments (meant to elicit SYN/ACK or RST segments),
ICMPv6 Port Unreachable, an IPv6 packet containing any suitable
payload and an unrecognized extension header (such that a ICMPv6
Parameter Problem error message is elicited), or,
o an IPv6 packet containing any suitable payload and an unrecognized o TCP segments that do not contain the ACK bit set (meant to elicit
RST segments),
o UDP datagrams (meant to elicit a UDP application response or an
ICMPv6 Port Unreachable),
o IPv6 packets containing any suitable payload and an unrecognized
extension header (meant to elicit ICMPv6 Parameter Problem error
messages), or,
o IPv6 packets containing any suitable payload and an unrecognized
option of type 10xxxxxx (such that a ICMPv6 Parameter Problem option of type 10xxxxxx (such that a ICMPv6 Parameter Problem
error message is elicited) error message is elicited)
Selecting an appropriate probe packet might help conceal the ongoing Selecting an appropriate probe packet might help conceal the ongoing
attack, but may also be actually necessary if host or network attack, but may also be actually necessary if host or network
configuration causes certain probe packets to be dropped. In some configuration causes certain probe packets to be dropped. In some
cases, it might be desirable to insert some IPv6 extension headers cases, it might be desirable to insert some IPv6 extension headers
before the actual payload, such that some filtering policies can be before the actual payload, such that some filtering policies can be
circumvented. circumvented.
skipping to change at page 31, line 30 skipping to change at page 32, line 38
some implementation. For example, Mac OS X employs IPv6 addresses some implementation. For example, Mac OS X employs IPv6 addresses
embedding IEEE-identifiers (rather than "privacy addresses") when embedding IEEE-identifiers (rather than "privacy addresses") when
responding to packets destined to a link-local multicast address, responding to packets destined to a link-local multicast address,
sourced from an on-link prefix. sourced from an on-link prefix.
A.3. Implementation of a IPv6 remote address-scanning tool A.3. Implementation of a IPv6 remote address-scanning tool
An IPv6 remote address scanning tool, could be implemented with the An IPv6 remote address scanning tool, could be implemented with the
following features: following features:
o The tool can be instructed to scan devices manufactured by a o The tool can be instructed to target specific address ranges (e.g.
specific vendor, such that only addresses resulting for the 2001:db8::0-10:0-1000)
corresponding OUIs are tried.
o The tool can be instructed to scan for SLAAC addresses of a
specific vendor, such that only addresses embedding the
corresponding IEEE OUIs are probed.
o The tool can be instructed to scan for SLAAC addresses that employ
a specific IEEE OUI.
o The tool can be instructed to discover virtual machines, such that o The tool can be instructed to discover virtual machines, such that
a given IPv6 prefix is only scanned for the address patterns a given IPv6 prefix is only scanned for the address patterns
resulting from virtual machines (as discussed earlier in this resulting from virtual machines.
document).
o The tool can be instructed to scan for low-byte or DHCPv6-like o The tool can be instructed to scan for low-byte addresses.
addresses.
o The tool can be instructed to scan for wordy-addresses, in which o The tool can be instructed to scan for wordy-addresses, in which
case the tool selects addresses based on a local dictionary. case the tool selects addresses based on a local dictionary.
o The tool can be instructed to scan for IPv6 addresses embedding
TCP/UDP service ports, in which case the tool selects addresses
based on a list of well-known service ports.
o The tool can be specified an IPv4 address range in use at the o The tool can be specified an IPv4 address range in use at the
target network, such that only IPv4-based IPv6 addresses are target network, such that only IPv4-based IPv6 addresses are
scanned. scanned.
In brute force mode, the tool can, at the very least: The scan6 tool of [IPv6-Toolkit] implements all these techniques/
features.
o Skip addresses resulting from unassigned OUIs.
o Skip addresses resulting from OUIs deemed as "legacy".
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
Huawei Technologies Huawei Technologies
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
 End of changes. 32 change blocks. 
103 lines changed or deleted 176 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/