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
late stage solution.
Signaling should be added to DHCP and RA to identify which servers
support the well known TSIG key.
This does not protect against attackers that can see the DNS
requests.
2. The Well Known Key
The well known key has a owner name of "." and uses HMAC-SHA256
[RFC4635] as its algorithm with a key of 256 zero bits.
Should it become necessary to roll the well known key's algorithm, an
updated RFC should be published with new algorithm and matching key
definition. The standard TSIG error response of NOTAUTH/BADALG can
be used to signal to try alternate algorithms. It is possible for
servers to support multiple algorithms simultaneously by trying each
in turn. Not all existing servers support trying multiple
algorithms/keys for the same name.
3. Using The Well Known Key
Clients should opportunistically attempt to use the well known key
and if they get an expected error they should fallback to not using
the well known key unless they have already had a successful
transaction using the well known key or have a priori knowledge that
the well known key is supported.
All members of a anycast cluster of servers should use the same well
known keys.
When sending a request a 64 bit nonce should be added to the TSIG
Other Data section to increase the entropy of the request. The TSIG
Other Data section currently unused in TSIG requests.
4. Old Servers
STD 13 [RFC1034] [RFC1035] compliant servers that do not support TSIG
will return FORMERR or ignore the TSIG in the request.
Old servers that support TSIG are expected to return NOTAUTH/BADKEY.
In practice other results are seen. The following contains the
results of sending a plain DNS query and the above well known key to
all DNS servers for the Alexa Top 1 Million sorted pairwise. It is
regenerated monthly.
Andrews Expires January 3, 2020 [Page 3]
Internet-Draft Defeating DNS/UDP Fragmentation Attacks July 2019
Alexa 1 Million - TSIG Well Know Key Handling Report (experimental)
[1]
5. Security Considerations
Using TSIG as a cryptographic checksum to defeat UDP fragmentation
attacks requires that there is sufficient entropy in the request to
have enough different MACs generatated. A plain DNS query only has
the current time and DNS query id to provide entropy. Additional
entropy is added by using DNS COOKIE and/or adding a nonce to the
TSIG Other Data data of the request.
Using a well known TSIG key does not fully protect against an
attacker that can see the request but it reduces the attack to a
plain response race rather than one that allows preloading the
fragmentation reassembly buffers.
6. References
6.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
RFC 4635, DOI 10.17487/RFC4635, August 2006,
<https://www.rfc-editor.org/info/rfc4635>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
6.2. URIs
[1] https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt
Andrews Expires January 3, 2020 [Page 4]
Internet-Draft Defeating DNS/UDP Fragmentation Attacks July 2019
Appendix A. Configuring Servers to support the Well Known TSIG Key
A.1. BIND 9
Add the following to named.conf. Some end-of-life versions do not
support HMAC-SHA256.
key "." {
algorithm hmac-sha256;
secret "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};
A.2. Other Vendors
Other DNS vendors please send me instructions for your servers.
Appendix B. Configuring Recursive Servers to send the Well Known TSIG
Key
B.1. BIND 9
Define the key as above and add multiple of the following to
named.conf for the servers you wish to send the well known TSIG key
to.
server <prefix> { keys "."; };
B.2. Other Vendors
Other DNS vendors please send me instructions for your servers.
Author's Address
M. Andrews
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Email: marka@isc.org
Andrews Expires January 3, 2020 [Page 5]