--- 1/draft-ietf-opsec-ipv6-host-scanning-06.txt 2015-04-30 12:15:04.087054360 -0700 +++ 2/draft-ietf-opsec-ipv6-host-scanning-07.txt 2015-04-30 12:15:04.159056098 -0700 @@ -1,19 +1,19 @@ opsec F. Gont Internet-Draft Huawei Technologies Obsoletes: 5157 (if approved) T. Chown Intended status: Informational University of Southampton -Expires: August 9, 2015 February 5, 2015 +Expires: November 1, 2015 April 30, 2015 Network Reconnaissance in IPv6 Networks - draft-ietf-opsec-ipv6-host-scanning-06 + draft-ietf-opsec-ipv6-host-scanning-07 Abstract IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 9, 2015. + This Internet-Draft will expire on November 1, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,43 +79,43 @@ 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 4. Leveraging the Domain Name System (DNS) for Network Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 5. Leveraging Local Name Resolution and Service Discovery - Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + Services . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22 7. Application Participation . . . . . . . . . . . . . . . . . . 22 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 9. Inspection of System Configuration and Log Files . . . . . . 23 10. Gleaning Information from Routing Protocols . . . . . . . . . 23 11. Gleaning Information from IP Flow Information Export (IPFIX) 23 12. Obtaining Network Information with traceroute6 . . . . . . . 23 - 13. Gleaning Information from Network Devices Using SNMP . . . . 23 + 13. Gleaning Information from Network Devices Using SNMP . . . . 24 14. Obtaining Network Information via Traffic Snooping . . . . . 24 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 17. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 25 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 19.1. Normative References . . . . . . . . . . . . . . . . . . 25 19.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Implementation of a full-fledged IPv6 address- scanning tool . . . . . . . . . . . . . . . . . . . 29 A.1. Host-probing considerations . . . . . . . . . . . . . . . 29 A.2. Implementation of an IPv6 local address-scanning tool . . 31 A.3. Implementation of a IPv6 remote address-scanning tool . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction The main driver for IPv6 [RFC2460] deployment is its larger address space [CPNI-IPv6]. This larger address space not only allows for an increased number of connected devices, but also introduces a number of subtle changes in several aspects of the resulting networks. One of these changes is the reduced host density (the number of hosts divided by the number of addresses) of typical IPv6 subnetworks: with default IPv6 subnets of /64, each subnet comprises more than 1.844 * @@ -939,31 +939,36 @@ [van-Dijk] describes an interesting technique that employs DNS reverse mappings for network reconnaissance. Essentially, the attacker walks through the "ip6.arpa" zone looking up PTR records, in the hopes of learning the IPv6 addresses of hosts in a given target network (assuming that the reverse mappings have been configured, of course). What is most interesting about this technique is that it can greatly reduce the IPv6 address search space. 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:db8:80::/32"), issuing queries for PTR records corresponding to + "2001:db8:80::/48"), issuing queries for PTR records corresponding to the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", "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 "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 contain an RCODE of 0 (no error). Otherwise, the response would contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this technique allows for a tremendous reduction in the "IPv6 address" search space. + [I-D.howard-isp-ip6rdns] analyzes different approaches and + considerations for ISPs in managing the ip6.arpa zone for IPv6 + address space assigned to many customers, which may affect the + technique described in this section. + 5. Leveraging Local Name Resolution and Service Discovery Services A number of protocols allow for unmanaged local name resolution and service. For example, multicast DNS (mDNS) [RFC6762] and DNS Service Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR) [RFC4795], are examples of such protocols. Besides the Graphical User Interfaces (GUIs) included in products supporting such protocols, command-line tools such as mdns-scan [mdns-scan] and mzclient can help discover IPv6 hosts employing @@ -1116,24 +1121,24 @@ reconnaissance techniques to be actively explored, as global deployment of IPv6 increases and. more specifically, as more IPv6-only devices are deployed. 18. Acknowledgements The authors would like to thank Ray Hunter, who provided valuable text that was readily incorporated into Section 3.2.1 of this document. - The authors would like to thank (in alphabetical order) Marc Heuse, - Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric - Vyncke, for providing valuable comments on earlier versions of this - document. + The authors would like to thank (in alphabetical order) Wesley + George, Marc Heuse, Ray Hunter, Libor Polcak, Tomoyuki Sahara, Jan + Schaumann, Arturo Servin, and Eric Vyncke, for providing valuable + comments on earlier versions of this document. Part of the contents of this document are based on the results of the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank the UK CPNI for their continued support. 19. References @@ -1203,47 +1208,52 @@ February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [I-D.gont-6man-ipv6-smurf-amplifier] Gont, F. and W. Liu, "Security Implications of IPv6 Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- amplifier-03 (work in progress), March 2013. + [I-D.howard-isp-ip6rdns] + Howard, L., "Reverse DNS in IPv6 for Internet Service + Providers", draft-howard-isp-ip6rdns-07 (work in + progress), February 2015. + [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, January 2015. [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and W. Will, "Recommendation on Stable IPv6 Interface Identifiers", draft-ietf-6man-default-iids-02 (work in progress), January 2015. [I-D.ietf-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", - draft-ietf-6man-ipv6-address-generation-privacy-03 (work - in progress), January 2015. + draft-ietf-6man-ipv6-address-generation-privacy-05 (work + in progress), April 2015. [I-D.ietf-dhc-stable-privacy-addresses] Gont, F. and W. Will, "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft- - ietf-dhc-stable-privacy-addresses-00 (work in progress), - October 2014. + ietf-dhc-stable-privacy-addresses-02 (work in progress), + April 2015. [I-D.ietf-opsec-v6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", draft-ietf- - opsec-v6-05 (work in progress), October 2014. + opsec-v6-06 (work in progress), March 2015. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). [V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm propagation strategies in an IPv6 Internet", ;login:, pages 70-76, February 2006,