Defeating DNS/UDP Fragmentation Attacks
draft-andrews-dnsop-defeat-frag-attack-00

Document Type Active Internet-Draft (individual)
Last updated 2019-07-02
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         M. Andrews
Internet-Draft                                                       ISC
Intended status: Standards Track                            July 2, 2019
Expires: January 3, 2020

                Defeating DNS/UDP Fragmentation Attacks
               draft-andrews-dnsop-defeat-frag-attack-00

Abstract

   It is possible to force a DNS server to fragment its response such
   that a fragmentation reassembly attack can insert records into the
   response.  This document uses TSIG with a well known key to defeat
   such attacks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Andrews                  Expires January 3, 2020                [Page 1]
Internet-Draft   Defeating DNS/UDP Fragmentation Attacks       July 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Well Known Key  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Using The Well Known Key  . . . . . . . . . . . . . . . . . .   3
   4.  Old Servers . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   Appendix A.  Configuring Servers to support the Well Known TSIG
                Key  . . . . . . . . . . . . . . . . . . . . . . . .   5
     A.1.  BIND 9  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     A.2.  Other Vendors . . . . . . . . . . . . . . . . . . . . . .   5
   Appendix B.  Configuring Recursive Servers to send the Well Known
                TSIG Key . . . . . . . . . . . . . . . . . . . . . .   5
     B.1.  BIND 9  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     B.2.  Other Vendors . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   It is possible to force a DNS server to fragment its response such
   that a fragmentation reassembly attack can insert records into the
   response.  This document uses TSIG with a well known key to defeat
   such attacks.

   Using TSIG [RFC2845] with a well known key effectively adds a
   crytographgically strong checksum to every DNS message.  When
   combined with DNS COOKIE [RFC7873] in the request, it is effectively
   impossible to guess the correct checksum for the response.  When DNS
   COOKIE is not used, a 64 bit nonce can be added to the Other Data
   section of the requests TSIG to achieve the same protection as it is
   part of the data that is hashed.

   Existing servers, that support TSIG, can be configured with the well
   known key allowing them to answer clients that send requests with the
   well known key.

   Existing clients, including recursive servers, that support TSIG, can
   be configured to send queries with the well known key for servers
   they regularly talk to after testing to see if the server has been
   configured with the well known key.

   Tools, like those used to generate the Alexa 1 Million - TSIG Well
   Know Key Handling Report (experimental) report referenced below, can
   be used periodically to generate lists of servers that support the
   well known TSIG key.  Alternatively one can configure a server to

Andrews                  Expires January 3, 2020                [Page 2]
Internet-Draft   Defeating DNS/UDP Fragmentation Attacks       July 2019

   send the well known key and have a exclusion list.  This would be a
Show full document text