draft-ietf-dnsop-reflectors-are-evil-02.txt		draft-ietf-dnsop-reflectors-are-evil-03.txt
	Network Working Group J. Damas		Network Working Group J. Damas
	Internet-Draft ISC		Internet-Draft ISC
	Expires: March 19, 2007 F. Neves		Intended status: Informational F. Neves
	Registro.br		Expires: August 17, 2007 Registro.br
	September 15, 2006		February 13, 2007
	Preventing Use of Recursive Nameservers in Reflector Attacks		Preventing Use of Recursive Nameservers in Reflector Attacks
	draft-ietf-dnsop-reflectors-are-evil-02.txt		draft-ietf-dnsop-reflectors-are-evil-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 19, 2007.		This Internet-Draft will expire on August 17, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes the use of default configured recursive		This document describes ways to prevent the use of default configured
	nameservers as reflectors on DOS attacks. Recommended configuration		recursive nameservers as reflectors on DOS attacks. Recommended
	as measures to mitigate the attack are given.		configuration as measures to mitigate the attack are given.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
	3. Recommended Configuration . . . . . . . . . . . . . . . . . . . 4		3. Recommended Configuration . . . . . . . . . . . . . . . . . . . 4
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . . 6		6.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 8		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Recently, DNS [RFC1034] has been named as a major factor in the		Recently, DNS [RFC1034] has been named as a major factor in the
	generation of massive amounts of network traffic used in Denial of		generation of massive amounts of network traffic used in Denial of
	Service (DoS) attacks. These attacks, called reflector attacks, are		Service (DoS) attacks. These attacks, called reflector attacks, are
	not due to any particular flaw in the design of the DNS or its		not due to any particular flaw in the design of the DNS or its
	implementations, asides perhaps the fact that DNS relies heavily on		implementations, aside perhaps the fact that DNS relies heavily on
	UDP, the easy abuse of which is at the source of the problem. They		UDP, the easy abuse of which is at the source of the problem. They
	have preferentially used DNS due to common default configurations		have preferentially used DNS due to common default configurations
	that allow for easy use of open recursive nameservers that make use		that allow for easy use of open recursive nameservers that make use
	of such a default configuration.		of such a default configuration.
	In addition, due to the small query-large response potential of the		In addition, due to the small query-large response potential of the
	DNS system it is easy to yield great amplification of the source		DNS system it is easy to yield great amplification of the source
	traffic as reflected traffic towards the victims.		traffic as reflected traffic towards the victims.
	DNS authority servers which do not provide recursion to clients can		DNS authoritative servers which do not provide recursion to clients
	also be used as amplifiers; however, the amplification potential is		can also be used as amplifiers; however, the amplification potential
	greatly reduced when authority servers are used. It is also not		is greatly reduced when authoritative servers are used. It is also
	practical to restrict access to authority servers to a subset of the		not practical to restrict access to authoritative servers to a subset
	Internet, since their normal operation relies on them being able to		of the Internet, since their normal operation relies on them being
	serve a wide audience, and hence the opportunities to mitigate the		able to serve a wide audience, and hence the opportunities to
	scale of an attack by modifying authority server configurations are		mitigate the scale of an attack by modifying authoritative server
	limited. This document's recommendations are concerned with		configurations are limited. This document's recommendations are
	recursive nameservers only.		concerned with recursive nameservers only.
	In this document we describe the characteristics of the attack and		In this document we describe the characteristics of the attack and
	recommend DNS server configurations that specifically alleviate the		recommend DNS server configurations that specifically alleviate the
	problem described, while pointing to the only truly real solution,		problem described, while pointing to the only truly real solution:
	the wide-scale deployment of ingress filtering to prevent use of		the wide-scale deployment of ingress filtering to prevent use of
	spoofed IP addresses [BCP38].		spoofed IP addresses [BCP38].
	2. Problem Description		2. Problem Description
	Because most DNS traffic is stateless by design, an attacker could		Because most DNS traffic is stateless by design, an attacker could
	start a DoS attack in the following way:		start a DoS attack in the following way:
	1. The attacker starts by configuring a record (LRECORD) on any zone		1. The attacker starts by configuring a record (LRECORD) on any zone
	he has access to (AZONE), normally with large RDATA and TTL.		he has access to (AZONE), normally with large RDATA and TTL.
	2. Taking advantage of clients (ZCLIENTS) on non-BCP38 networks, the		2. Taking advantage of clients (ZCLIENTS) on non-BCP38 networks, the
	attacker then crafts a query using the source address of their		attacker then crafts a query for LRECORD using the source address
	target victim and sends it to a open recursive nameserver (ORNS).		of their target victim and sends it to an open recursive
			nameserver (ORNS).
	3. Each ORNS proceeds with the resolution, caches the LRECORD and		3. Each ORNS proceeds with the resolution, caches the LRECORD and
	finally sends it to the target. After this first lookup, access		finally sends it to the target. After this first lookup, access
	to the authoritative nameservers for AZONE is normally no longer		to the authoritative nameservers for AZONE is normally no longer
	necessary. The LRECORD will remain cached for the duration of		necessary. The LRECORD will remain cached for the duration of
	the TTL at the ORNS even if the AZONE is corrected.		the TTL at the ORNS even if the AZONE is corrected.
	4. Cleanup of the AZONE might, depending on the implementation used		4. Cleanup of the AZONE might, depending on the implementation used
	in the ORNS, afford a way to clean the cached LRECORD from the		in the ORNS, afford a way to clean the cached LRECORD from the
	ORNS. This would possibly involve queries luring the ORNS to		ORNS. This would possibly involve queries luring the ORNS to
	lookup information for the same name that is being used in the		lookup information for the same name that is being used in the
	amplification.		amplification.
	Because the characteristics of the attack normally involve a low		Because the characteristics of the attack normally involve a low
	volume of packets amongst all the kinds of actors besides the victim		volume of packets amongst all the kinds of actors besides the victim
	(AZONE, ZCLIENTS, ORNS), it's unlikely any one of them would notice		(AZONE, ZCLIENTS, ORNS), it's unlikely any one of them would notice
	their involvement based on traffic pattern changes.		their involvement based on traffic pattern changes.
	skipping to change at page 4, line 22		skipping to change at page 4, line 22
	volume of packets amongst all the kinds of actors besides the victim		volume of packets amongst all the kinds of actors besides the victim
	(AZONE, ZCLIENTS, ORNS), it's unlikely any one of them would notice		(AZONE, ZCLIENTS, ORNS), it's unlikely any one of them would notice
	their involvement based on traffic pattern changes.		their involvement based on traffic pattern changes.
	Taking advantage of ORNS that support EDNS0 [RFC2671], the		Taking advantage of ORNS that support EDNS0 [RFC2671], the
	amplification factor (response packet size / query packet size) could		amplification factor (response packet size / query packet size) could
	be around 80. With this amplification factor a relatively small army		be around 80. With this amplification factor a relatively small army
	of ZCLIENTS and ORNS could generate gigabits of traffic towards the		of ZCLIENTS and ORNS could generate gigabits of traffic towards the
	victim.		victim.
	Even if this attach is only really possible due to non-deployment of		Even if this attack is only really possible due to non-deployment of
	BCP 38, this amplification attack is easier to leverage because for		BCP 38, this amplification attack is easier to leverage because for
	historical reasons, out of times when the Internet was a much closer-		historical reasons, from times when the Internet was a much closer-
	knit community, some nameserver implementations have been made		knit community, some nameserver implementations have been made
	available with default configurations that when used for recursive		available with default configurations that when used for recursive
	nameservers made the server accessible to all hosts on the Internet.		nameservers made the server accessible to all hosts on the Internet.
	For years this was a convenient and helpful configuration, enabling		For years this was a convenient and helpful configuration, enabling
	wider availability of services. As this document aims to make		wider availability of services. As this document aims to make
	apparent, it is now much better to be conscious of ones own		apparent, it is now much better to be conscious of ones own
	nameserver services and focus the delivery of services on the		nameserver services and focus the delivery of services on the
	intended audience of those services, be they a university campus, an		intended audience of those services, be they a university campus, an
	enterprise or an ISP's customers. The authors also want to draw the		enterprise or an ISP's customers. The authors also want to draw the
	attention of small network operators and private server managers who		attention of small network operators and private server managers who
	decide to operate nameservers with the aim of optimising their DNS		decide to operate nameservers with the aim of optimising their DNS
	service, as these are more likely to use default configurations as		service, as these are more likely to use default configurations as
	shipped by implementors.		shipped by implementors.
	3. Recommended Configuration		3. Recommended Configuration
	From the description of the problem in the previous section it		From the description of the problem in the previous section it
	follows that the solution to this sort of attacks is the wide		follows that the solution to these sort of attacks is the wide
	deployment of ingress filtering [BCP38] in routers to prevent use of		deployment of ingress filtering [BCP38] in routers to prevent use of
	address spoofing as a viable course of action to elicit the attacks.		address spoofing as a viable course of action to prevent the attacks.
			In situations were more complex network setups are in place, "Ingress
			Filtering for Multihomed Network" [BCP84] maybe a useful additional
			reference.
	Nonetheless, the fact remains that DNS servers acting as open		Nonetheless, the fact remains that DNS servers acting as open
	recursive servers provide an easy means to obtain great rates of		recursive servers provide an easy means to obtain great rates of
	amplification for attack traffic, requiring only a small amount of		amplification for attack traffic, requiring only a small amount of
	traffic from the attack sources to generate a vast amount of traffic		traffic from the attack sources to generate a vast amount of traffic
	towards the victim.		towards the victim.
	The authors also want to note that with the increasing length of		The authors also want to note that with the increasing length of
	authoritative DNS responses derived from deployment of DNSSEC and		authoritative DNS responses derived from deployment of DNSSEC and
	NAPTR as used in ENUM services, authoritative servers will eventually		NAPTR as used in ENUM services, authoritative servers will eventually
	skipping to change at page 5, line 48		skipping to change at page 6, line 5
	running a local instance of a caching nameserver or forwarder that		running a local instance of a caching nameserver or forwarder that
	will be able to TSIG sign the queries and send them on to the		will be able to TSIG sign the queries and send them on to the
	recursive nameserver of choice.		recursive nameserver of choice.
	In nameservers that do not need to be providing recursive service,		In nameservers that do not need to be providing recursive service,
	for instance servers that are meant to be authoritative only, turn		for instance servers that are meant to be authoritative only, turn
	recursion off completely. In general, it is a good idea to keep		recursion off completely. In general, it is a good idea to keep
	recursive and authoritative services separate as much as practical.		recursive and authoritative services separate as much as practical.
	This, of course, depends on local circumstances.		This, of course, depends on local circumstances.
			By default, nameservers SHOULD not offer recursive service to
			external networks.
	4. Acknowledgments		4. Acknowledgments
	Joe Abley, Andrew Sullivan		The authors would like to acknowledge the helpful input and comments
			of Joe Abley, Olafur Gudmundsson, Pekka Savola, and Andrew Sullivan.
	5. Security Considerations		5. Security Considerations
	This document does not create any new security issues for the DNS		This document does not create any new security issues for the DNS
	protocol.		protocol.
	It's not excessive to repeat that, although recommended		It's not excessive to repeat that, although recommended
	configurations described in this document could alleviate the		configurations described in this document could alleviate the
	problem, the only solution to all kinds of source address spoofing		problem, the only solution to source address spoofing problems is the
	problems is the wide-scale deployment of Ingress Filtering to prevent		wide-scale deployment of Ingress Filtering to prevent use of spoofed
	use of spoofed IP addresses [BCP38].		IP addresses [BCP38], [BCP84].
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",		[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
	RFC 2671, August 1999.		RFC 2671, August 1999.
	skipping to change at page 7, line 5		skipping to change at page 6, line 47
	[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (		[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
	SIG(0)s)", RFC 2931, September 2000.		SIG(0)s)", RFC 2931, September 2000.
	6.2. Informative References		6.2. Informative References
	[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
			[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
			Networks", BCP 84, RFC 3704, March 2004.
	Authors' Addresses		Authors' Addresses
	Joao Damas		Joao Damas
	Internet Systems Consortium, Inc.		Internet Systems Consortium, Inc.
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	US		US
	Phone: +1 650 423 1300		Phone: +1 650 423 1300
	Email: Joao_Damas@isc.org		Email: Joao_Damas@isc.org
	skipping to change at page 8, line 5		skipping to change at page 8, line 5
	Frederico A. C. Neves		Frederico A. C. Neves
	NIC.br / Registro.br		NIC.br / Registro.br
	Av. das Nacoes Unidas, 11541, 7		Av. das Nacoes Unidas, 11541, 7
	Sao Paulo, SP 04578-000		Sao Paulo, SP 04578-000
	BR		BR
	Phone: +55 11 5509 3511		Phone: +55 11 5509 3511
	Email: fneves@registro.br		Email: fneves@registro.br
	URI: http://registro.br/		URI: http://registro.br/
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 8, line 29		skipping to change at page 8, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 22 change blocks.
	49 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/