draft-ietf-opsec-ipv6-host-scanning-06.txt   draft-ietf-opsec-ipv6-host-scanning-07.txt 
opsec F. Gont opsec F. Gont
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 5157 (if approved) T. Chown Obsoletes: 5157 (if approved) T. Chown
Intended status: Informational University of Southampton Intended status: Informational University of Southampton
Expires: August 9, 2015 February 5, 2015 Expires: November 1, 2015 April 30, 2015
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-06 draft-ietf-opsec-ipv6-host-scanning-07
Abstract Abstract
IPv6 offers a much larger address space than that of its IPv4 IPv6 offers a much larger address space than that of its IPv4
counterpart. An IPv6 subnet of size /64 can (in theory) accommodate counterpart. An IPv6 subnet of size /64 can (in theory) accommodate
approximately 1.844 * 10^19 hosts, thus resulting in a much lower approximately 1.844 * 10^19 hosts, thus resulting in a much lower
host density (#hosts/#addresses) than is typical in IPv4 networks, host density (#hosts/#addresses) than is typical in IPv4 networks,
where a site typically has 65,000 or less unique addresses. As a where a site typically has 65,000 or less unique addresses. As a
result, it is widely assumed that it would take a tremendous effort result, it is widely assumed that it would take a tremendous effort
to perform address scanning attacks against IPv6 networks, and to perform address scanning attacks against IPv6 networks, and
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 9, 2015. This Internet-Draft will expire on November 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18
3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21
4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21
4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22
7. Application Participation . . . . . . . . . . . . . . . . . . 22 7. Application Participation . . . . . . . . . . . . . . . . . . 22
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22
9. Inspection of System Configuration and Log Files . . . . . . 23 9. Inspection of System Configuration and Log Files . . . . . . 23
10. Gleaning Information from Routing Protocols . . . . . . . . . 23 10. Gleaning Information from Routing Protocols . . . . . . . . . 23
11. Gleaning Information from IP Flow Information Export (IPFIX) 23 11. Gleaning Information from IP Flow Information Export (IPFIX) 23
12. Obtaining Network Information with traceroute6 . . . . . . . 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 14. Obtaining Network Information via Traffic Snooping . . . . . 24
15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
17. Security Considerations . . . . . . . . . . . . . . . . . . . 24 17. Security Considerations . . . . . . . . . . . . . . . . . . . 25
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.1. Normative References . . . . . . . . . . . . . . . . . . 25 19.1. Normative References . . . . . . . . . . . . . . . . . . 25
19.2. Informative References . . . . . . . . . . . . . . . . . 26 19.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Implementation of a full-fledged IPv6 address- Appendix A. Implementation of a full-fledged IPv6 address-
scanning tool . . . . . . . . . . . . . . . . . . . 29 scanning tool . . . . . . . . . . . . . . . . . . . 29
A.1. Host-probing considerations . . . . . . . . . . . . . . . 29 A.1. Host-probing considerations . . . . . . . . . . . . . . . 29
A.2. Implementation of an IPv6 local address-scanning tool . . 31 A.2. Implementation of an IPv6 local address-scanning tool . . 31
A.3. Implementation of a IPv6 remote address-scanning tool . . 32 A.3. Implementation of a IPv6 remote address-scanning tool . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The main driver for IPv6 [RFC2460] deployment is its larger address The main driver for IPv6 [RFC2460] deployment is its larger address
space [CPNI-IPv6]. This larger address space not only allows for an space [CPNI-IPv6]. This larger address space not only allows for an
increased number of connected devices, but also introduces a number increased number of connected devices, but also introduces a number
of subtle changes in several aspects of the resulting networks. One of subtle changes in several aspects of the resulting networks. One
of these changes is the reduced host density (the number of hosts of these changes is the reduced host density (the number of hosts
divided by the number of addresses) of typical IPv6 subnetworks: with divided by the number of addresses) of typical IPv6 subnetworks: with
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 21, line 37 skipping to change at page 21, line 37
[van-Dijk] describes an interesting technique that employs DNS [van-Dijk] describes an interesting technique that employs DNS
reverse mappings for network reconnaissance. Essentially, the reverse mappings for network reconnaissance. Essentially, the
attacker walks through the "ip6.arpa" zone looking up PTR records, in 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 the hopes of learning the IPv6 addresses of hosts in a given target
network (assuming that the reverse mappings have been configured, of network (assuming that the reverse mappings have been configured, of
course). What is most interesting about this technique is that it course). What is most interesting about this technique is that it
can greatly reduce the IPv6 address search space. can greatly reduce the IPv6 address search space.
Basically, an attacker would walk the ip6.arpa zone corresponding to Basically, an attacker would walk the ip6.arpa zone corresponding to
a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for
"2001:db8:80::/32"), issuing queries for PTR records corresponding to "2001:db8:80::/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.", 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.
[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 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) [RFC6762] and DNS Service service. For example, multicast DNS (mDNS) [RFC6762] and DNS Service
Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution
(LLMNR) [RFC4795], are examples of such protocols. (LLMNR) [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
skipping to change at page 25, line 23 skipping to change at page 25, line 29
reconnaissance techniques to be actively explored, as global reconnaissance techniques to be actively explored, as global
deployment of IPv6 increases and. more specifically, as more deployment of IPv6 increases and. more specifically, as more
IPv6-only devices are deployed. IPv6-only devices are deployed.
18. Acknowledgements 18. Acknowledgements
The authors would like to thank Ray Hunter, who provided valuable The authors would like to thank Ray Hunter, who provided valuable
text that was readily incorporated into Section 3.2.1 of this text that was readily incorporated into Section 3.2.1 of this
document. document.
The authors would like to thank (in alphabetical order) Marc Heuse, The authors would like to thank (in alphabetical order) Wesley
Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric George, Marc Heuse, Ray Hunter, Libor Polcak, Tomoyuki Sahara, Jan
Vyncke, for providing valuable comments on earlier versions of this Schaumann, Arturo Servin, and Eric Vyncke, for providing valuable
document. 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.
19. References 19. References
skipping to change at page 27, line 16 skipping to change at page 27, line 23
February 2013. February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[I-D.gont-6man-ipv6-smurf-amplifier] [I-D.gont-6man-ipv6-smurf-amplifier]
Gont, F. and W. Liu, "Security Implications of IPv6 Gont, F. and W. Liu, "Security Implications of IPv6
Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf-
amplifier-03 (work in progress), March 2013. amplifier-03 (work in progress), March 2013.
[I-D.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, [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", RFC 7421, January 2015. in IPv6 Addressing", RFC 7421, January 2015.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will, Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-02 (work in progress), draft-ietf-6man-default-iids-02 (work in progress),
January 2015. January 2015.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-03 (work draft-ietf-6man-ipv6-address-generation-privacy-05 (work
in progress), January 2015. in progress), April 2015.
[I-D.ietf-dhc-stable-privacy-addresses] [I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and W. Will, "A Method for Generating Gont, F. and W. Will, "A Method for Generating
Semantically Opaque Interface Identifiers with Dynamic Semantically Opaque Interface Identifiers with Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", draft- Host Configuration Protocol for IPv6 (DHCPv6)", draft-
ietf-dhc-stable-privacy-addresses-00 (work in progress), ietf-dhc-stable-privacy-addresses-02 (work in progress),
October 2014. April 2015.
[I-D.ietf-opsec-v6] [I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", draft-ietf- 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] [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,
 End of changes. 14 change blocks. 
17 lines changed or deleted 27 lines changed or added

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