One document matched: draft-ietf-dnsop-reflectors-are-evil-05.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2671 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml'>
<!ENTITY rfc2845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2845.xml'>
<!ENTITY rfc2931 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2931.xml'>
]>

<rfc category="bcp" ipr="full3978" 
     docName="draft-ietf-dnsop-reflectors-are-evil-05.txt">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc compact="yes" ?>
  <?rfc strict="yes" ?>
  
  <front>
    <title abbrev="Preventing Rec. NS in Reflector Attacks">
    Preventing Use of Recursive Nameservers in Reflector Attacks</title>

    <author initials='J' surname="Damas" fullname='Joao Damas'>
      <organization abbrev="ISC">
	Internet Systems Consortium, Inc.
      </organization>
      <address>
	<postal>
	  <street>950 Charter Street</street>
	  <city>Redwood City</city> <region>CA</region>
       	  <code>94063</code>
	  <country>US</country>
	</postal>
	<phone>+1 650 423 1300</phone>
	<email>Joao_Damas@isc.org</email>
	<uri>http://www.isc.org/</uri>
      </address>
    </author>
    <author initials='F' surname="Neves" fullname='Frederico A. C. Neves'>
      <organization abbrev="Registro.br">
	NIC.br / Registro.br
      </organization>
      <address>
	<postal>
	  <street>Av. das Nacoes Unidas, 11541, 7</street>
	  <city>Sao Paulo</city> <region>SP</region>
	  <code>04578-000</code>
	  <country>BR</country>
	</postal>
	<phone>+55 11 5509 3511</phone>
	<email>fneves@registro.br</email>
	<uri>http://registro.br/</uri>
      </address>
    </author>
    <date day="3" month="December" year="2007"/>
    
    <abstract><t>This document describes ways to prevent the use of
    default configured recursive nameservers as reflectors in Denial
    of Service (DoS) attacks. Recommended configuration as measures to
    mitigate the attack are given.</t></abstract>
    
  </front>
  
  <middle>
    <section title="Introduction">
      <t>Recently, DNS <xref target="RFC1034"/> has been named as a
      major factor in the generation of massive amounts of network
      traffic used in Denial of Service (DoS) attacks. These attacks,
      called reflector attacks, are not due to any particular flaw in
      the design of the DNS or its implementations, aside perhaps the
      fact that DNS relies heavily on UDP, the easy abuse of which is
      at the source of the problem. They have preferentially used DNS
      due to common default configurations that allow for easy use of
      open recursive nameservers that make use of such a default
      configuration.</t>

      <t>In addition, due to the small query-large response potential
      of the DNS system it is easy to yield great amplification of the
      source traffic as reflected traffic towards the victims.</t>

      <t>DNS authoritative servers which do not provide recursion to
      clients can also be used as amplifiers; however, the
      amplification potential is greatly reduced when authoritative
      servers are used. It is also not practical to restrict access to
      authoritative servers to a subset of the Internet, since their
      normal operation relies on them being able to serve a wide
      audience, and hence the opportunities to mitigate the scale of
      an attack by modifying authoritative server configurations are
      limited. This document's recommendations are concerned with
      recursive nameservers only.</t>

      <t>In this document we describe the characteristics of the
      attack and recommend DNS server configurations that specifically
      alleviate the problem described, while pointing to the only
      truly real solution: the wide-scale deployment of ingress
      filtering to prevent use of spoofed IP addresses <xref
      target="BCP38"/>.</t>
    </section>

    <section anchor="terminology" title="Document Terminology">
      <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
      "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described
      in <xref target="RFC2119"/>.</t>
    </section>

    <section title="Problem Description">
      <t>Because most DNS traffic is stateless by design, an attacker
      could start a DoS attack in the following way:</t>
      
      <t><list style='numbers'>

	<t>The attacker starts by configuring a record on any zone he
	has access to, normally with large RDATA and TTL.</t>

	<t>Taking advantage of clients on non-BCP38 networks, the
	attacker then crafts a query using the source address of their
	target victim and sends it to an open recursive nameserver
	(ORNS).</t>

	<t>Each open recursive nameserver proceeds with the
	resolution, caches the record and finally sends it to the
	target. After this first lookup, access to the authoritative
	nameservers is normally no longer necessary. The record will
	remain cached for the duration of the TTL at the open
	recursive nameserver even if it's deleted from the zone.</t>

	<t>Cleanup of the zone might, depending on the implementation
	used in the open recursive nameserver, afford a way to clean
	the 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 amplification.</t>
      </list></t>
      
      <t>Because the characteristics of the attack normally involve a
      low volume of packets amongst all the kinds of actors besides
      the victim, it's unlikely any one of them would notice their
      involvement based on traffic pattern changes.</t>

      <t>Taking advantage of open recursive nameserver that support
      EDNS0 <xref target="RFC2671"/>, the amplification factor
      (response packet size / query packet size) could be around
      80. With this amplification factor a relatively small army of
      clients and open recursive nameservers could generate gigabits
      of traffic towards the victim.</t>

      <t>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.</t>
      
      <t>Even if this attack is only really possible due to
      non-deployment of BCP38, this amplification attack is easier to
      leverage because for historical reasons, from times when the
      Internet was a much closer-knit community, some nameserver
      implementations have been made available with default
      configurations that when used for recursive nameservers made the
      server accessible to all hosts on the Internet.</t>

      <t>For years this was a convenient and helpful configuration,
      enabling wider availability of services. As this document aims
      to make apparent, it is now much better to be conscious of ones
      own nameserver services and focus the delivery of services on
      the intended audience of those services, be they a university
      campus, an enterprise or an ISP's customers. The target audience
      also includes operators of small network operators and private
      server managers who decide to operate nameservers with the aim
      of optimising their DNS service, as these are more likely to use
      default configurations as shipped by implementors.</t>
    </section>
    
    <section title="Recommended Configuration">
      <t>In this section we describe the Best Current Practice for
      operating recursive nameservers. Following these recommendations
      would reduce the chances of having a given recursive nameserver
      be used for the generation of an amplification attack.</t>

      <t>The generic recommendation to nameserver operators is to use
      the means provided by the implementation of choice to provide
      recursive name lookup service only to the intended
      clients. Client authorization can be usually done in several
      ways:</t>
      <t><list style='symbols'>
	<t>IP address based authorization. Use the IP source address
	of the DNS queries and filter them through an Access Control
	List (ACL) to service only the intended clients. This is
	easily applied if the recursive name server's service area is
	a reasonably fixed IP address range that is protected against
	external address spoofing, usually the local network.</t>
      </list></t>
      <t><list style='symbols'>
	<t>Incoming Interface based selection. Use the incoming interface
	for the query as a discriminator to select which clients are to be
	served. This is of particular applicability for SOHO devices, such
	as broadband routers that include embedded recursive name servers.</t>
      </list></t>
      <t><list style='symbols'>
	<t>Use TSIG <xref target="RFC2845"/> or SIG(0) <xref
	target="RFC2931"/> signed queries to authenticate the
	clients. This is a less error prone method, which allows
	server operators to provide service to clients who change IP
	address frequently (e.g. roaming clients). The current
	drawback of this method is that very few stub resolver
	implementations support TSIG or SIG(0) signing of outgoing
	queries.  The effective use of this method implies in most
	cases 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 recursive nameserver of choice.</t>
      </list></t>
      <t><list style='symbols'>
	<t>For mobile users use a local caching name server running on
	the mobile device or use a Virtual Private Network to a
	trusted server.</t>
      </list></t>

      <t>In nameservers that do not need to be providing recursive
      service, for instance servers that are meant to be authoritative
      only, turn recursion off completely. In general, it is a good
      idea to keep recursive and authoritative services separate as
      much as practical.  This, of course, depends on local
      circumstances.</t>

      <t>Even with all these recommendations network operators should
      consider deployment of ingress filtering <xref target="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" <xref
      target="BCP84"/> maybe a useful additional reference.</t>

      <t>By default, nameservers SHOULD NOT offer recursive service to
      external networks.</t>
    </section>
    
    <section title="Security Considerations">
      <t>This document does not create any new security issues for the
      DNS protocol, it deals with a weakness in implementations.</t>
    </section>

    <section title="Acknowledgments">
      <t>The authors would like to acknowledge the helpful input and
      comments of Joe Abley, Olafur Gudmundsson, Pekka Savola, Andrew
      Sullivan and Tim Polk.</t>
    </section> 

    <section title="IANA Considerations">
      <t>This document does not define a registry and does not require
      any IANA action.</t>
    </section>

  </middle>
  
  <back>
    <references title="Normative References">
      &rfc1034;
      &rfc2119;
      &rfc2671;
      &rfc2845;
      &rfc2931;
    </references>
    <references title="Informative References">
      <reference anchor='BCP38'>
	<front>
	  <title>Network Ingress Filtering: Defeating Denial of
	  Service Attacks which employ IP Source Address
	  Spoofing</title>
	  <author initials='P.' surname='Ferguson' fullname='P. Ferguson'>
	  <organization /></author>
	  <author initials='D.' surname='Senie' fullname='D. Senie'>
	  <organization /></author>
	  <date year='2000' month='May' />
	</front>
	<seriesInfo name='BCP' value='38' />
	<seriesInfo name='RFC' value='2827' />
	<format type='TXT' octets='21258' target='ftp://ftp.isi.edu/in-notes/rfc2827.txt' />
      </reference>
      
      <reference anchor='BCP84'>
	<front>
	  <title>Ingress Filtering for Multihomed Networks</title>
	  <author initials='F.' surname='Baker' fullname='F. Baker'>
	  <organization /></author>
	  <author initials='P.' surname='Savola' fullname='P. Savola'>
	  <organization /></author>
	  <date year='2004' month='March' />
	</front>
	<seriesInfo name='BCP' value='84' />
	<seriesInfo name='RFC' value='3704' />
	<format type='TXT' octets='35942' target='ftp://ftp.isi.edu/in-notes/rfc3704.txt' />
      </reference>
    </references>
  </back>
</rfc>