draft-ietf-dnsop-reflectors-are-evil-04.txt		draft-ietf-dnsop-reflectors-are-evil-05pre.txt
	Network Working Group J. Damas		Network Working Group J. Damas
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Best Current F. Neves		Intended status: Best Current F. Neves
	Practice Registro.br		Practice Registro.br
	Expires: January 10, 2008 July 9, 2007		Expires: January 10, 2008 July 9, 2007
	Preventing Use of Recursive Nameservers in Reflector Attacks		Preventing Use of Recursive Nameservers in Reflector Attacks
	draft-ietf-dnsop-reflectors-are-evil-04.txt		draft-ietf-dnsop-reflectors-are-evil-05pre.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 2, line 10		skipping to change at page 2, line 10
	This document describes ways to prevent the use of default configured		This document describes ways to prevent the use of default configured
	recursive nameservers as reflectors in Denial of Service (DoS)		recursive nameservers as reflectors in Denial of Service (DoS)
	attacks. Recommended configuration as measures to mitigate the		attacks. Recommended configuration as measures to mitigate the
	attack are given.		attack are given.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 3		2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 3
	3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3		3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
	4. Recommended Configuration . . . . . . . . . . . . . . . . . . . 4		4. Recommended Configuration . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . . 7		8.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, aside perhaps the fact that DNS relies heavily on		implementations, aside perhaps the fact that DNS relies heavily on
	skipping to change at page 3, line 48		skipping to change at page 3, line 48
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Problem Description		3. 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 on any zone he has
	he has access to (AZONE), normally with large RDATA and TTL.		access to, normally with large RDATA and TTL.
	2. Taking advantage of clients (ZCLIENTS) on non-BCP38 networks, the		2. Taking advantage of clients on non-BCP38 networks, the attacker
	attacker then crafts a query for LRECORD using the source address		then crafts a query using the source address of their target
	of their target victim and sends it to an open recursive		victim and sends it to an open recursive nameserver (ORNS).
	nameserver (ORNS).		3. Each open recursive nameserver proceeds with the resolution,
	3. Each ORNS proceeds with the resolution, caches the LRECORD and		caches the record and finally sends it to the target. After this
	finally sends it to the target. After this first lookup, access		first lookup, access to the authoritative nameservers is normally
	to the authoritative nameservers for AZONE is normally no longer		no longer necessary. The record will remain cached for the
	necessary. The LRECORD will remain cached for the duration of		duration of the TTL at the open recursive nameserver even if it's
	the TTL at the ORNS even if the AZONE is corrected.		deleted from the zone.
	4. Cleanup of the AZONE might, depending on the implementation used		4. Cleanup of the zone might, depending on the implementation used
	in the ORNS, afford a way to clean the cached LRECORD from the		in the open recursive nameserver, afford a way to clean the
	ORNS. This would possibly involve queries luring the ORNS to		cached record from the open recursive nameserver. This would
			possibly involve queries luring the open recursive nameserver 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		it's unlikely any one of them would notice their involvement based on
	their involvement based on traffic pattern changes.		traffic pattern changes.
	Taking advantage of ORNS that support EDNS0 [RFC2671], the		Taking advantage of open recursive nameserver that support EDNS0
	amplification factor (response packet size / query packet size) could		[RFC2671], the amplification factor (response packet size / query
	be around 80. With this amplification factor a relatively small army		packet size) could be around 80. With this amplification factor a
	of ZCLIENTS and ORNS could generate gigabits of traffic towards the		relatively small army of clients and open recursive nameservers could
	victim.		generate gigabits of traffic towards the victim.
			With the increasing length of authoritative DNS responses derived
			from deployment of DNSSEC and NAPTR as used in ENUM services,
			authoritative servers will eventually be more useful as actors in
			this sort of amplification attack.
	Even if this attack 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, from 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
	skipping to change at page 4, line 51		skipping to change at page 5, line 8
	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 target audience also includes		enterprise or an ISP's customers. The target audience also includes
	operators of small network operators and private server managers who		operators 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.
	4. Recommended Configuration		4. Recommended Configuration
	From the description of the problem in the previous section it
	follows that the solution to these sort of attacks is the wide
	deployment of ingress filtering [BCP38] in routers to prevent use of
	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
	recursive servers provide an easy means to obtain great rates of
	amplification for attack traffic, requiring only a small amount of
	traffic from the attack sources to generate a vast amount of traffic
	towards the victim.
	With the increasing length of authoritative DNS responses derived
	from deployment of DNSSEC and NAPTR as used in ENUM services,
	authoritative servers will eventually be more useful as actors in
	this sort of amplification attack, stressing even more the need for
	deployment of BCP 38.
	In this section we describe the Best Current Practice for operating		In this section we describe the Best Current Practice for operating
	recursive nameservers. Following these recommendations would reduce		recursive nameservers. Following these recommendations would reduce
	the chances of having a given recursive nameserver be used for the		the chances of having a given recursive nameserver be used for the
	generation of an amplification attack.		generation of an amplification attack.
	The generic recommendation to nameserver operators is to use the		The generic recommendation to nameserver operators is to use the
	means provided by the implementation of choice to provide recursive		means provided by the implementation of choice to provide recursive
	name lookup service only to the intended clients. Client		name lookup service only to the intended clients. Client
	authentication can be usually done in several ways:		authentication can be usually done in several ways:
	skipping to change at page 6, line 6		skipping to change at page 5, line 39
	authenticate the clients. This is a less error prone method,		authenticate the clients. This is a less error prone method,
	which allows server operators to provide service to clients who		which allows server operators to provide service to clients who
	change IP address frequently (e.g. roaming clients). The current		change IP address frequently (e.g. roaming clients). The current
	drawback of this method is that very few stub resolver		drawback of this method is that very few stub resolver
	implementations support TSIG or SIG(0) signing of outgoing		implementations support TSIG or SIG(0) signing of outgoing
	queries. The effective use of this method implies in most cases		queries. The effective use of this method implies in most cases
	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.
			o For mobile users use a Virtual Private Network.
	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.
			Even with all these recommendations network operators should consider
			deployment of ingress filtering [BCP38] in routers to prevent use of
			address spoofing as a viable course of action. In situations where
			more complex network setups are in place, "Ingress Filtering for
			Multihomed Network" [BCP84] maybe a useful additional reference.
	By default, nameservers SHOULD NOT offer recursive service to		By default, nameservers SHOULD NOT offer recursive service to
	external networks.		external networks.
	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, it deals with a weakness in implementations.		protocol, it deals with a weakness in implementations.
	It's not excessive to repeat that, although recommended
	configurations described in this document could alleviate the
	problem, the only solution to source address spoofing problems is the
	wide-scale deployment of Ingress Filtering to prevent use of spoofed
	IP addresses [BCP38], [BCP84].
	6. Acknowledgments		6. Acknowledgments
	The authors would like to acknowledge the helpful input and comments		The authors would like to acknowledge the helpful input and comments
	of Joe Abley, Olafur Gudmundsson, Pekka Savola, and Andrew Sullivan.		of Joe Abley, Olafur Gudmundsson, Pekka Savola, and Andrew Sullivan.
	7. IANA Considerations		7. IANA Considerations
	This document does not define a registry and does not require any		This document does not define a registry and does not require any
	IANA action.		IANA action.
End of changes. 11 change blocks.
	51 lines changed or deleted		39 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/