doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc5358.txt b/doc/rfc/rfc5358.txt
new file mode 100644
index 0000000..a370f8e
--- /dev/null
+++ b/doc/rfc/rfc5358.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           J. Damas
+Request for Comments: 5358                                           ISC
+BCP: 140                                                        F. Neves
+Category: Best Current Practice                              Registro.br
+                                                            October 2008
+
+
+      Preventing Use of Recursive Nameservers in Reflector Attacks
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes ways to prevent the use of default configured
+   recursive nameservers as reflectors in Denial of Service (DoS)
+   attacks.  It provides recommended configuration as measures to
+   mitigate the attack.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Document Terminology  . . . . . . . . . . . . . . . . . . . . . 2
+   3.  Problem Description . . . . . . . . . . . . . . . . . . . . . . 2
+   4.  Recommended Configuration . . . . . . . . . . . . . . . . . . . 4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Damas & Neves            Best Current Practice                  [Page 1]
+
+RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008
+
+
+1.  Introduction
+
+   Recently, DNS [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, except that DNS relies heavily on UDP, the easy
+   abuse of which is at the source of the problem.  The attacks 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.
+
+   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.
+
+   DNS authoritative servers that 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
+   impractical 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; 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.
+
+   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 real solution: the
+   wide-scale deployment of ingress filtering to prevent use of spoofed
+   IP addresses [BCP38].
+
+2.  Document Terminology
+
+   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 [RFC2119].
+
+3.  Problem Description
+
+   Because most DNS traffic is stateless by design, an attacker could
+   start a DoS attack in the following way:
+
+   1.  The attacker starts by configuring a record on any zone he has
+       access to, normally with large RDATA and Time to Live (TTL).
+
+
+
+
+
+
+Damas & Neves            Best Current Practice                  [Page 2]
+
+RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008
+
+
+   2.  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.
+
+   3.  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 at
+       the open recursive nameserver for the duration of the TTL, even
+       if it's deleted from the zone.
+
+   4.  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.
+
+   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.
+
+   Taking advantage of an open recursive nameserver that supports EDNS0
+   [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.
+
+   With the increasing length of authoritative DNS responses derived
+   from deployment of DNSSEC [RFC4033] and NAPTR resource records as
+   used in ENUM services, authoritative servers will eventually be more
+   useful as actors in this sort of amplification attack.
+
+   Even if this amplification attack is only possible due to non-
+   deployment of BCP38, it is easier to leverage because of historical
+   reasons.  When the Internet was a much closer-knit community, some
+   nameserver implementations were made available with default
+   configurations that, when used for recursive nameservers, made the
+   server accessible to all hosts on the Internet.
+
+   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 one's 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 networks and private server managers who
+
+
+
+Damas & Neves            Best Current Practice                  [Page 3]
+
+RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008
+
+
+   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.
+
+4.  Recommended Configuration
+
+   In this section we describe the Best Current Practice for operating
+   recursive nameservers.  Following these recommendations would reduce
+   the chances of any given recursive nameserver being used for the
+   generation of an amplification attack.
+
+   The generic recommendation to nameserver operators is to use the
+   means provided by the implementation of choice to provide recursive
+   name lookup service to only the intended clients.  Client
+   authorization can usually be done in several ways:
+
+   o  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 nameserver's service area is a reasonably fixed IP
+      address range that is protected against external address spoofing,
+      usually the local network.
+
+   o  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 (Small
+      Office, Home Office) devices, such as broadband routers that
+      include embedded recursive nameservers.
+
+   o  TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to authenticate
+      the clients.  This is a less error prone method that 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.
+
+   o  For mobile users, use a local caching nameserver running on the
+      mobile device or use a Virtual Private Network to a trusted
+      server.
+
+   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.
+
+
+
+Damas & Neves            Best Current Practice                  [Page 4]
+
+RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008
+
+
+   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
+   external networks.
+
+5.  Security Considerations
+
+   This document does not create any new security issues for the DNS
+   protocol, it deals with a weakness in implementations.
+
+   Deployment of SIG(0) transaction security [RFC2931] should consider
+   the caveats with SIG(0) computational expense as it uses public key
+   cryptography rather than the symmetric keys used by TSIG [RFC2845].
+   In addition, the identification of the appropriate keys needs similar
+   mechanisms as those for deploying TSIG or, alternatively, the use of
+   DNSSEC [RFC4033] signatures (RRSIGs) over the KEY RRs if published in
+   DNS.  This will in turn require the appropriate management of DNSSEC
+   trust anchors.
+
+6.  Acknowledgments
+
+   The authors would like to acknowledge the helpful input and comments
+   of Joe Abley, Olafur Gudmundsson, Pekka Savola, Andrew Sullivan, and
+   Tim Polk.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+
+
+
+
+Damas & Neves            Best Current Practice                  [Page 5]
+
+RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008
+
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+7.2.  Informative References
+
+   [BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
+              Defeating Denial of Service Attacks which employ IP Source
+              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
+
+   Joao Damas
+   Internet Systems Consortium, Inc.
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 650 423 1300
+   EMail: Joao_Damas@isc.org
+   URI:   http://www.isc.org/
+
+
+   Frederico A. C. Neves
+   NIC.br / Registro.br
+   Av. das Nacoes Unidas, 11541, 7
+   Sao Paulo, SP  04578-000
+   BR
+
+   Phone: +55 11 5509 3511
+   EMail: fneves@registro.br
+   URI:   http://registro.br/
+
+
+
+
+
+
+
+
+
+
+
+
+
+Damas & Neves            Best Current Practice                  [Page 6]
+
+RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   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
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Damas & Neves            Best Current Practice                  [Page 7]
+