Internet DRAFT - draft-wkumari-dnsext-echo
draft-wkumari-dnsext-echo
Network Working Group W. Kumari
Internet-Draft Google
Intended status: Informational R. Arends
Expires: August 30, 2012 Nominet
February 27, 2012
EDNS Echo.
draft-wkumari-dnsext-echo-00
Abstract
This document describes a DNS protocol extension to allow for
arbritry data to be inserted into a DNS Request and have that same
data be returned in a DNS Reply.
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 http://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 August 30, 2012.
Copyright Notice
Copyright (c) 2012 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
(http://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.
Kumari & Arends Expires August 30, 2012 [Page 1]
Internet-Draft EDNS Echo February 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Increasing the size of the ID space . . . . . . . . . . . . 3
3. ECHO Option format . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Presentation format . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Kumari & Arends Expires August 30, 2012 [Page 2]
Internet-Draft EDNS Echo February 2012
1. Introduction
RFC2671 [RFC2671] specifies an extension mechanism for DNS. This
document describes an EDNS option to allow for arbritry data to be
inserted into a DNS Request and have that same data be returned in a
DNS Reply. This functionality can be used to increase the effective
size of the ID field [RFC1035, Section 4.1.1 [RFC1035]] and to aid in
diagnostics.
1.1. Requirements notation
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].
2. Use cases
2.1. Increasing the size of the ID space
The Header section of the DNS Message format contains a 16-bit ID
field (see [RFC1035, Section 4.1.1 [RFC1035]). This field is used to
match replies to their queries. If an attacker is able to predict
this field he may be able to spoof a reply and perform a DNS cache
poisining attack. By inserting arbritary data into the ECHO OPTION-
DATA in a query (and checking that the same data is returned in the
response), an iterative resolver can protect itself against this type
of attack. Note that the resolver needs to add additional steps to
protect against a downgrade attack. This technique does not protect
against a man in the middle attack.
To avoid maintaining additional state for each query, the sender can
algorithmically generate the ECHO OPTION-DATA. As an example it
could generate this data field by calculating a hash over the
concatenation of various fileds (such as the QNAME and the ID field)
and a secret.
3. ECHO Option format
The OPTION-CODE for the ECHO option is TBD.
The OPTION-DATA for the ECHO option is an opaque byte string, the
semantics of which are deliberately left outside the protocol.
The OPTION-DATA only has meaning to the sender. The software that
generates the response or any intermediate device SHOULD NOT try and
infer anything from the data.
Kumari & Arends Expires August 30, 2012 [Page 3]
Internet-Draft EDNS Echo February 2012
3.1. Presentation format
User interfaces MUST read and write the contents of the ECHO option
as a sequence of hexadecimal digits, two digits per payload octet.
The ECHO payload is binary data. Any comparison between ECHO
payloads MUST be a comparison of the raw binary data. Copy
operations MUST NOT assume that the raw payload is null-terminated.
4. IANA Considerations
The IANA is requested to assign a value from the "DNS EDNS0 Options"
registry, setting the name to be "ECHO" and referencing this
document.
The code for the option should be TBD.
5. Security Considerations
A common form of denial of service attack is the reflected DNS
amplification attack. In this attack an attacker spoofs DNS requests
from the victim that will result in a much larger reply (the
amplification factor). While the attacker could include a large
amount of data in the ECHO payload of the spoofed DNS requests, this
doesn't create any amplification.
The ECHO option could be used for DNS tunneling and exfiltration of
data.
6. Acknowledgements
The authors wish to thank some folk.
7. References
7.1. Normative References
[IANA.AS_Numbers]
IANA, "Autonomous System (AS) Numbers",
<http://www.iana.org/assignments/as-numbers>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Kumari & Arends Expires August 30, 2012 [Page 4]
Internet-Draft EDNS Echo February 2012
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
7.2. Informative References
[I-D.ietf-sidr-iana-objects]
Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects
issued by IANA", draft-ietf-sidr-iana-objects-03 (work in
progress), May 2011.
Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ]
Changes from $undefined to -00.
o Initial document generation.
Notes / references:
o rfc2671.txt - Extension Mechanisms for DNS (EDNS0)
o rfc5001.txt - DNS Name Server Identifier (NSID) Option
Authors' Addresses
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Roy Arends
Nominet
Minerva House, Edmund Halley Road
Oxford OX4 6LB
UK
Email: roy@nominet.org.uk
Kumari & Arends Expires August 30, 2012 [Page 5]