idnits 2.17.1 draft-jabley-as112-being-attacked-help-help-00.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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (June 18, 2006) is 6521 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: 'I-D.jabley-as112-ops' is defined on line 301, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Afilias 4 Expires: December 20, 2006 June 18, 2006 6 I'm Being Attacked by PRISONER.IANA.ORG! 7 draft-jabley-as112-being-attacked-help-help-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Many sites connected to the Internet make use of IPv4 addresses which 41 are not globally unique. Examples are the addresses designated in 42 RFC1918 for private use within individual sites. 44 Hosts should never normally send reverse DNS queries for those 45 addresses on the public Internet. However, such queries are 46 frequently observed. Authority servers are deployed to provide 47 authoritative answers to such queries as part of a loosely- 48 coordinated effort known as the AS112 project. 50 Since queries sent to AS112 servers are usually not intentional, the 51 replies received back from those servers are typically unexpected. 52 Unexpected inbound traffic can trigger alarms on intrusion detection 53 systems and firewalls, and operators of such systems often mistakenly 54 believe that they are being attacked. 56 This document provides background information and technical advice to 57 those firewall operators. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . 4 63 3. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Reverse DNS for Private-Use Addresses . . . . . . . . . . . . 6 65 5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 8 67 7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . 9 68 8. AS112 Contact Information . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 11.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Introduction 80 Readers of this document may well have experienced an alarm from a 81 firewall or an intrusion-detection system, triggered by unexpected 82 inbound traffic from the Internet. The traffic probably appeared to 83 originate from one of the following hosts: 85 o PRISONER.IANA.ORG (192.175.48.1) 87 o BLACKHOLE-1.IANA.ORG (192.175.48.6) 89 o BLACKHOLE-2.IANA.ORG (192.175.48.42) 91 The published contacts for those hosts may well have suggested that 92 you consult this document. 94 If you are following up on such an event, you are encouraged to 95 follow your normal security procedures and take whatever action you 96 consider to be be appropriate. This document contains information 97 which may assist you. 99 2. Private-Use Addresses 101 Many sites connected to the Internet make use of address blocks 102 designated in [RFC1918] for private use. Examples of such addresses 103 are 10.1.30.20, 172.18.24.100 and 192.168.1.1. 105 Because these ranges of addresses are used by many sites all over the 106 world, each individual address can only ever have local significance. 107 For example, the host numbered 192.168.18.234 in one site almost 108 certainly has nothing to do with a host with the same address located 109 in a different site. 111 3. Reverse DNS 113 The Domain Name System (DNS) [RFC1034] can be used to obtain a name 114 for a particular network address. The process by which this happens 115 is as follows: 117 1. The network address is rearranged in order to construct a name 118 which can be looked up in the DNS. For example, the IPv4 address 119 10.3.70.25 corresponds to the DNS name 25.70.3.10.IN-ADDR.ARPA. 121 2. A DNS query is constructed for that name, requesting a DNS record 122 of the type "PTR". 124 3. The DNS query is sent to a resolver. 126 4. If a response is received in response to the query, the answer 127 will typically indicate either the hostname corresponding to the 128 network address, or the fact that no hostname can be found. 130 This procedure is generally carried out automatically by software, 131 and is hence largely hidden from users and administrators. 132 Applications might have reason to look up an IP address in order to 133 gather extra information for a log file, for example. 135 4. Reverse DNS for Private-Use Addresses 137 As noted in Section 2, private-use addresses have only local 138 significance. This means that sending queries out to the Internet is 139 not sensible: there is no way for the public DNS to provide a useful 140 answer to a question which has no global meaning. 142 Despite the fact that the public DNS cannot provide answers, many 143 sites have misconfigurations in the way they connect to the Internet 144 which results to such queries relating to internal infrastructure 145 being sent outside the site. From the perspective of the public DNS, 146 these queries are junk -- they cannot be answered usefully and result 147 in unnecessary traffic being received by the nameservers which 148 underpin the operation of the public DNS (the so-called root 149 servers). 151 To isolate this traffic, and reduce the load on the rest of the DNS 152 infrastructure, dedicated servers have been deployed in the Internet 153 to receive and reply to these junk queries. These servers are 154 deployed in many places in a loosely-coordinated effort known as the 155 "AS112 Project". More details about the AS112 Project can be found 156 at . 158 5. AS112 Nameservers 160 The nameservers responsible for answering queries relating to 161 private-use addresses are as follows: 163 o PRISONER.IANA.ORG (192.175.48.1) 165 o BLACKHOLE-1.IANA.ORG (192.175.48.6) 167 o BLACKHOLE-2.IANA.ORG (192.175.48.42) 169 A request sent to one of these servers will result in a response 170 being returned to the client. The response will typically be a UDP 171 datagram, although it's perfectly valid for requests to be made over 172 TCP. In both cases the source port of packets returning to the site 173 which originated the DNS request will be 53. 175 6. Inbound Traffic from AS112 Servers 177 Where firewalls or intrusion detection systems (IDS) are configured 178 to block traffic received from AS112 servers, superficial review of 179 the traffic may seem alarming to site administrators. 181 o Since requests directed ultimately to AS112 servers are usually 182 triggered automatically by applications, review of firewall logs 183 may indicate a large number of policy violations occurring over an 184 extended period of time. 186 o Where responses from AS112 servers are blocked by firewalls, hosts 187 will often retry, often with a relatively high frequency. This 188 can cause inbound traffic to be misclassified as a denial-of- 189 service (DoS) attack. In some case the source ports used by 190 individual hosts for successive retries increases in a predictable 191 fashion (e.g. monotonically), which can cause the replies from the 192 AS112 server to resemble a port scan. 194 o A site administrator may attempt to perform active measurement of 195 the remote host in response to alarms raised by inbound traffic, 196 e.g. initiating a port scan in order to gather information about 197 the host which is apparently attacking the site. Such a scan will 198 usually result in additional inbound traffic to the site 199 performing the measurement, e.g. an apparent flood of ICMP 200 messages which may trigger additional firewall alarms and 201 obfuscate the process of identifying the original problem traffic. 203 7. Corrective Measures 205 A site which receives responses from one of the nameservers listed in 206 Section 5 is probably under no immediate danger, and the traffic 207 associated with those responses probably requires no emergency action 208 by the site concerned. However, this document cannot aspire to 209 dictate the security policy of individual sites, and it is recognised 210 that many sites will have perfectly valid policies which dictate that 211 corrective measures should be taken to stop the responses from AS112 212 servers. 214 It should be noted, however, that the operators of AS112 nameservers 215 which are generating the responses described in this document are not 216 ultimately responsible for the inbound traffic received by the site: 217 that traffic is generated in response to queries which are sent out 218 from the site, and so the only effective measures to stop the inbound 219 traffic is to prevent the original queries from being made. 221 Possible measures which might be taken to prevent these queries 222 include: 224 1. Stop hosts from making these reverse DNS queries in the first 225 place. In some cases servers can be configured not to perform 226 reverse DNS lookups, for example. As a general site-wide 227 approach, however, this measure is frequently difficult to 228 implement due to the large number of hosts and applications 229 involved. 231 2. Block reverse DNS queries to the AS112 servers from leaving the 232 site using firewalls between the site and the Internet. Although 233 this might appear to be sensible, such a measure might have 234 unintended consequences: the inability to receive an answer to 235 reverse DNS queries might lead to long DNS lookup timeouts, for 236 example, which could cause applications to malfunction. 238 3. Configure all DNS resolvers in the site to answer authoritatively 239 for the zones corresponding to the private-use address blocks in 240 use. This should prevent resolvers from ever needing to send 241 these queries to the public DNS. Guidance and recommendations 242 for this aspect of resolver configuration can be found in 243 [I-D.andrews-full-service-resolvers]. 245 4. Implement a private AS112 node within the site. Guidance for 246 constructing an AS112 node may be found in [I-D.jabley-as112- 247 ops]. 249 8. AS112 Contact Information 251 Operational contact information for the network addresses of AS112 252 servers is registered with Regional Internet Registries (RIRs). 253 Readers who continue to have concerns about traffic received from 254 AS112 servers after reading this document are encouraged to contact 255 the AS112 Network Operations Centre. 257 More information about the AS112 project can be found at 258 . 260 9. IANA Considerations 262 The AS112 nameservers are all named under the domain IANA.ORG (see 263 Section 5). The IANA is the organisation responsible for the 264 coordination of many technical aspects of the Internet's basic 265 infrastructure. The AS112 project nameservers provide a public 266 service to the Internet which is sanctioned by and operated in 267 coordination with the IANA. 269 10. Security Considerations 271 The purpose of this document is to help site administrators properly 272 identify traffic received from AS112 nodes, and to provide background 273 information to allow appropriate measures to be taken in response to 274 it. 276 Hosts should never normally send queries to AS112 servers: queries 277 relating to private-use addresses should be answered locally within a 278 site. Hosts which send queries to AS112 servers may well leak 279 information relating to private infrastructure to the public network, 280 which could represent a security risk. 282 11. References 284 11.1. Normative References 286 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 287 STD 13, RFC 1034, November 1987. 289 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 290 E. Lear, "Address Allocation for Private Internets", 291 BCP 5, RFC 1918, February 1996. 293 11.2. Informative References 295 [I-D.andrews-full-service-resolvers] 296 Andrews, M., "Configuration Issues Facing Full Service DNS 297 Resolvers In The Presence of Private Network Addressing", 298 draft-andrews-full-service-resolvers-02 (work in 299 progress), February 2006. 301 [I-D.jabley-as112-ops] 302 Abley, J. and W. Maton, "AS112 Nameserver Operations", 303 June 2006. 305 Appendix A. Change History 307 This section to be removed prior to publication. 309 It is proposed that this document be published as an informational 310 RFC. 312 00 Initial draft. 314 Author's Address 316 Joe Abley 317 Afilias Canada Corp. 318 Suite 204, 4141 Yonge Street 319 Toronto, ON M2P 2A8 320 Canada 322 Phone: +1 416 673 4176 323 Email: jabley@ca.afilias.info 325 Intellectual Property Statement 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; nor does it represent that it has 332 made any independent effort to identify any such rights. Information 333 on the procedures with respect to rights in RFC documents can be 334 found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use of 339 such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository at 341 http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at 347 ietf-ipr@ietf.org. 349 Disclaimer of Validity 351 This document and the information contained herein are provided on an 352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 354 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 355 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 356 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 359 Copyright Statement 361 Copyright (C) The Internet Society (2006). This document is subject 362 to the rights, licenses and restrictions contained in BCP 78, and 363 except as set forth therein, the authors retain all their rights. 365 Acknowledgment 367 Funding for the RFC Editor function is currently provided by the 368 Internet Society.