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/