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.