idnits 2.17.1 draft-chown-v6ops-port-scanning-implications-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 283. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 299), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 6) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2004) is 7219 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 241, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '1') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '2') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '3') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations T. Chown 2 Internet-Draft University of Southampton 3 Expires: January 17, 2005 July 19, 2004 5 IPv6 Implications for TCP/UDP Port Scanning 6 draft-chown-v6ops-port-scanning-implications-01 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 17, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The 128 bits of IPv6 address space is considerably bigger than the 32 40 bits of address space in IPv4. In particular, the IPv6 subnets to 41 which hosts attach will by default have 64 bits of host address 42 space. As a result, traditional methods of remote TCP or UDP port 43 scanning to discover open or running services on a host will 44 potentially become far less computationally feasible, due to the 45 larger search space in the subnet. This document discusses that 46 property of IPv6 subnets, and describes related issues for site 47 administrators of IPv6 networks to consider. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Target Address Space for Port Scanning . . . . . . . . . . . . 3 53 2.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3 Reducing the IPv6 Search Space . . . . . . . . . . . . . . 4 56 2.4 DNS considerations . . . . . . . . . . . . . . . . . . . . 4 57 2.5 Dual-stack networks . . . . . . . . . . . . . . . . . . . 4 58 3. Alternatives for Attackers . . . . . . . . . . . . . . . . . . 5 59 4. Recommendations for Site Administrators . . . . . . . . . . . 5 60 4.1 Use of IPv6 Privacy Addresses . . . . . . . . . . . . . . 5 61 4.2 DHCPv6 Configuration . . . . . . . . . . . . . . . . . . . 5 62 4.3 Defensive Scanning . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . 7 69 1. Introduction 71 The 128 bits of IPv6 [1] address space is considerably bigger than 72 the 32 bits of address space in IPv4. In particular, the IPv6 73 subnets to which hosts attach will by default have 64 bits of host 74 address space. As a result, traditional methods of remote TCP or UDP 75 port scanning to discover open or running services on a host will 76 potentially become far less computationally feasible, due to the 77 larger search space in the subnet. This document discusses that 78 property of IPv6 subnets, and describes related issues for site 79 administrators of IPv6 networks to consider. 81 It must be remembered that the defense of a network must not rely on 82 the obscurity of the hosts on that network. Such a feature or 83 property is only one measure in a set of measures that may be 84 applied. However, with a growing usage of IPv6 devices in open 85 networks likely, and security becoming more likely an issue for the 86 end devices, such considerations should be given some weight where to 87 implement appropriate measures is of little cost to the 88 administrator. 90 Port scanning is quite a prevalent tactic from would-be attackers. 91 The author observes that a typical university firewall will generate 92 many Megabytes of log files on a daily basis purely from port 93 scanning activity. 95 It is also worth noting that worms that spread by scanning target 96 networks for hosts to re-attack have become more common in recent 97 times. Thus a much more sparsely address-populated IPv6 network will 98 have a more innate defense to such forms of worm infection, although 99 there may still be significant scanning traffic generated. 101 2. Target Address Space for Port Scanning 103 2.1 IPv4 105 A typical IPv4 subnet may have 8 bits reserved for host addressing. 106 In such a case, a remote attacker need only probe at most 256 107 addresses to determine if a particular open service is running on a 108 host in that subnet. At one probe per second, such a scan may take 109 under 5 minutes to complete. 111 2.2 IPv6 113 A typical IPv6 subnet will have 64 bits reserved for host addressing. 114 In such a case, a remote attacker needs to probe 2^64 addresses to 115 determine if a particular open service is running on a host in that 116 subnet. At a very conservative one probe per second, such a scan may 117 take some 5 billion years to complete. A more rapid probe will still 118 be limited to (effectively) infinite time for the whole address 119 space. 121 2.3 Reducing the IPv6 Search Space 123 The IPv6 host address space through which an attacker may search can 124 be reduced in at least two ways. First, the attacker may rely on the 125 administrator conveniently numbering their hosts [prefix]::1 upwards. 127 Second, in the case of statelessly autoconfiguring [1] hosts, the 128 host part of the address will take a well-known format that includes 129 Ethernet vendor prefix and the "fffe" stuffing. For such hosts, if 130 the Ethernet vendor is known, the search space may be reduced to 24 131 bits (with a one probe per second scan then taking 194 days). Even 132 where the exact vendor is not known, using a set of common vendor 133 prefixes can reduce the search space. 135 Even if the vendor code is not known, the search space can be reduced 136 by using well-known, common vendor codes. 138 Further reductions may be possible if the attacker knows the target 139 is using 6over4, ISATAP, or other techniques that derive low-order 140 bits from IPv4 addresses (though in this case, unless they are using 141 IPv4 NAT, the IPv4 addresses may be probed anyway). 143 2.4 DNS considerations 145 Any servers that are DNS listed, e.g. MX mail relays, or web 146 servers, will remain open to probing from the very fact that their 147 IPv6 addresses will be DNS registered. Where a site uses sequential 148 host numbering, publishing just one address may lead to a threat upon 149 the other hosts. 151 There is a relation between port scanning and DNS zone transfers. In 152 the IPv4 world, this relationship is very weak because the IPv4 space 153 is densely populated and a DNS zone transfer (usually) doesn't help 154 an attacker target a port scan significantly. In the IPv6 world, a 155 zone transfer is much more likely to narrow the number of targeted 156 hosts. This implies restricting zone transfers is (more) important 157 for IPv6. 159 2.5 Dual-stack networks 161 Full advantage of the increased IPv6 address space in terms of 162 reslience to port scanning may not be gained until IPv6-only networks 163 and devices become more commonplace, given that most IPv6 hosts are 164 currently dual stack, with (more readily scannable) IPv4 connectivity 165 also. However, many applications or services (e.g. new peer-to-peer 166 applications) on the (dual stack) hosts may emerge that are only 167 accessible over IPv6, and that thus can only be discovered by IPv6 168 port scanning. 170 3. Alternatives for Attackers 172 If IPv6 port-scanning becomes infeasible, attackers will need to find 173 new methods to identify IPv6 addresses for subsequent port scanning. 174 One such method would be the harvesting of IPv6 addresses, either in 175 transit or from recorded logs such as web site logs. Another may be 176 to inspect the Received from: or other header lines in archived email 177 or Usenet news messages. 179 IPv6-enabled hosts on local subnets may still be discovered through 180 probing the "all hosts" link local multicast address. This implies 181 that if an attacker can compromise one remote host, they may then 182 learn addresses of the hosts in the same subnet on the remote 183 network. 185 In IPv6 networks, attackers may also switch to using more aggressive 186 yet subtle methods of attack, e.g. by using worms or virii that may 187 attach to or attack the new IPv6 applications (e.g. peer-to-peer 188 messaging). 190 4. Recommendations for Site Administrators 192 There are some methods that site administrators can apply to make the 193 task for IPv6 port scanning attackers harder. We describe such 194 methods in this section. 196 4.1 Use of IPv6 Privacy Addresses 198 By using the IPv6 Privacy Extensions [3] the hosts in the network 199 would only ever connect to external sites using their (temporary) 200 privacy address. While an attacker may be able to port scan that 201 address if they do so quickly upon observing the address, the threat 202 or risk is reduced. An example implementation of RFC3041 already 203 deployed has privacy addresses active for one day, but such addresses 204 reachable for seven days. Note that an RFC3041 host may have a 205 separate static global IPv6 address by which it can also be reached. 207 4.2 DHCPv6 Configuration 209 The administrator could configure DHCPv6 so that the first addresses 210 allocated from the pool begin much higher in the address space than 211 [prefix]::1. 213 DHCPv6 also includes an option to use Privacy Extension [3] 214 addresses, i.e. temporary addresses, as described in Section 12 of 215 the DHCPv6 [4] specification. 217 4.3 Defensive Scanning 219 The problem faced by the attacker for an IPv6 network is also faced 220 by a site administrator looking for vulnerabilities in their own 221 network's systems. The administrator may have the advantage of being 222 on-link for scanning purposes though. 224 5. Security Considerations 226 There are no specific security considerations in this document 227 outside of the topic of discussion itself. 229 6. Acknowledgements 231 Thanks are due to people in the 6NET project for discussion of this 232 topic, including Pekka Savola (CSC/FUNET), Christian Strauf (JOIN 233 Project, University of Muenster) and Martin Dunmore (Lancaster), as 234 well as David Malone (TCD, Dublin). 236 7 Informative References 238 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 239 Specification", RFC 2460, December 1998. 241 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 242 Autoconfiguration", RFC 2462, December 1998. 244 [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless 245 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 247 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 248 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 249 RFC 3315, July 2003. 251 Author's Address 253 Tim Chown 254 University of Southampton 256 Southampton, Hampshire SO17 1BJ 257 United Kingdom 259 EMail: tjc@ecs.soton.ac.uk 261 Intellectual Property Statement 263 The IETF takes no position regarding the validity or scope of any 264 Intellectual Property Rights or other rights that might be claimed to 265 pertain to the implementation or use of the technology described in 266 this document or the extent to which any license under such rights 267 might or might not be available; nor does it represent that it has 268 made any independent effort to identify any such rights. Information 269 on the procedures with respect to rights in RFC documents can be 270 found in BCP 78 and BCP 79. 272 Copies of IPR disclosures made to the IETF Secretariat and any 273 assurances of licenses to be made available, or the result of an 274 attempt made to obtain a general license or permission for the use of 275 such proprietary rights by implementers or users of this 276 specification can be obtained from the IETF on-line IPR repository at 277 http://www.ietf.org/ipr. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights that may cover technology that may be required to implement 282 this standard. Please address the information to the IETF at 283 ietf-ipr@ietf.org. 285 Disclaimer of Validity 287 This document and the information contained herein are provided on an 288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 290 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 291 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 292 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Copyright Statement 297 Copyright (C) The Internet Society (2004). This document is subject 298 to the rights, licenses and restrictions contained in BCP 78, and 299 except as set forth therein, the authors retain all their rights. 301 Acknowledgment 303 Funding for the RFC Editor function is currently provided by the 304 Internet Society.