Internet DRAFT - draft-reid-dnsext-aleatoric
draft-reid-dnsext-aleatoric
DNSEXT J. Reid
Internet-Draft RTFM Ltd
Intended status: Standards Track August 6, 2008
Expires: February 7, 2009
A DNS Resource Record for Additional Entropy
<draft-reid-dnsext-aleatoric-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 7, 2009.
Reid Expires February 7, 2009 [Page 1]
Internet-Draft Extra Entropy August 2008
Abstract
A scheme to defend against cache poisoning attacks against the Domain
Name System (DNS) by predicting the ID and source port number of
outgoing queries is described in this draft. It proposes a new
resource record to provide a mechanism to introduce additional
entropy into DNS queries.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. AL RR Format . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Query Generation . . . . . . . . . . . . . . . . . . . . . 6
4.2. Server Processing . . . . . . . . . . . . . . . . . . . . 6
4.3. Client Processing of Responses . . . . . . . . . . . . . . 7
4.4. Other applications of the AR Record Type . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Reid Expires February 7, 2009 [Page 2]
Internet-Draft Extra Entropy August 2008
1. 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 BCP 14, RFC2119
[RFC2119].
Reid Expires February 7, 2009 [Page 3]
Internet-Draft Extra Entropy August 2008
2. Introduction
The core DNS protocol is defined in RFC1034[RFC1034],
RFC1035[RFC1035] and clarified in RFC2181[RFC2181]. It is a
replicated hierarchical distributed database system that provides
information fundamental to Internet operations, such as name to
address mapping.
One difficulty which affects most DNS implementations is a
susceptibility to cache poisoning attacks as a result of forging DNS
responses. There are only 16 bits of random data for expressing a
query ID, making it a frequent target for forgery. [In fairness the
query ID was never intended to provide resilience to forgery attacks.
It was designed to allow a resolving name server to differentiate
between responses to the outstanding queries it had sent to some
other, presumably authoritative, name server.] Until recently most
DNS server implementations used a small set of fixed port numbers for
outgoing queries. This made the task of forging a response to a DNS
query somewhat straightforward. Stub resolvers can be vulnerable to
forgery attacks because they generally rely on the underlying
operating system to select a port number for their DNS queries and
may also use predictable query IDs. If these are insufficiently
random, forging responses to queries from stub resolvers may not pose
much of a challenge to attackers.
Current defences against forgery of DNS responses include transaction
authentication schemes such as TSIG RFC2845[RFC2845] and Secure DNS
(DNSSEC) RFC4033[RFC4033] RFC4034[RFC4034] RFC4037[RFC4035]. These
can be difficult to deploy and operate, particularly for non-experts.
TSIG is usually impractical outside environments where clients and
servers are under the same administrative control. While DNSSEC
provides integrity protection of DNS responses, it is not yet widely
deployed. Considerable time and effort will be required before
adoption of DNSSEC is ubiquitous.
This document proposes an interim solution that could be used until
widespread deployment of DNSSEC. It advocates the introduction of a
new resource record type, AL, to add extra entropy to DNS queries,
minimising ther potential exposure to DNS forgery attacks.
Reid Expires February 7, 2009 [Page 4]
Internet-Draft Extra Entropy August 2008
3. AL RR Format
A new RR type whose mnemonic is AL (aleatoric) and type code FOO is
proposed. All RDATA in the proposed AL record are sent in network
byte order (see Section 2.3.2 of RFC1034). The AL record's RDATA
consists of a fixed field of two octets containing a count of the
number of octets in the following variable length field. This
variable length field SHOULD contain random data.
ZS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| COUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ENTROPY /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where: COUNT Number of octets in the ENTROPY field ENTROPY Random
data
Reid Expires February 7, 2009 [Page 5]
Internet-Draft Extra Entropy August 2008
4. Protocol Operation
Use of this resource record for defending against forgery attacks is
broadly comparable to the scheme used in RFC2845. AL resource
records will generally be related to one DNS query/response
transaction. Therefore there is no value in storing or
retransmitting them. This means that AL resource records should be
treated as meta-RRs and MUST NOT be cached.
4.1. Query Generation
A client generates an AL record on the fly by populating it with
suitably random data and a count of the number of octets of that
data. This is then inserted into the Additional Section of the query
and the ARCOUNT incremented accordingly. If the AL record cannot be
added to the query without causing it to be truncated, the client
MUST either adjust the message to allow the AL record to be added or
use TCP to make the query. Clients MUST NOT include more than one AL
record in the Additional Section of each query. The client MUST
retain a copy of the random data for each query until a response is
received or the query times out. To maximise the opportunity for
label compression, the name of the AL record SHOULD be identical to
the QNAME in the query's Question Section.
4.2. Server Processing
Servers MUST NOT include more than one AL record in the Additional
Section of a response. If a server receives a query with more than
one AL record in the Additional Section, the query MUST be discarded
and a FORMERR (RCODE = 1) returned to the client. When a server
receives a query containing an AL record in the Additional Section,
it MUST ensure this is copied to the Additional Section of the
corresponding reply that it constructs. If the AL record cannot be
added to the response without causing it to be truncated, the server
MAY adjust the message by discarding other data from the Additional
Section. A server MUST NOT discard any transaction signature from
the Additional Section to make room for an AL record. In some
circumstances, the amount of data in the reply may make it impossible
to include an AL record in the Additional Section without causing
truncation. In these cases the server MUST send a response
consisting of empty Answer and Authority Sections, the original
Question Section and the client's AL record in the Additional
Section. This reply MUST set the TC bit to signal truncation and set
the RCODE to 0 (NOERROR). The client SHOULD at this point retry the
request using TCP in the manner described in Section 4.2.2 of
RFC1035.
Reid Expires February 7, 2009 [Page 6]
Internet-Draft Extra Entropy August 2008
4.3. Client Processing of Responses
On receipt of a response containing an AL record in the Additional
Section, the client SHOULD compare this to the random data it had
generated for the original query. If these are not identical, the
client MUST discard the reply and the corresponding state information
for that query. When the original random data and the contents of
the returned AL record's data are identical, the response is returned
to the resolver that initiated the query in the conventional manner.
A response containing more than one AL record in the Additional
Section MUST be discarded.
4.4. Other applications of the AR Record Type
The motivation of this document is the addition of extra randomness
to DNS queries to make it harder to forge responses to them. However
it is also envisaged that clients could make explicit lookups for
this record type as a way of obtaining random data from a name
server: for example if the server has access to a strong source of
such data.
Reid Expires February 7, 2009 [Page 7]
Internet-Draft Extra Entropy August 2008
5. Operational Considerations
The generation and volume of random data for AR records need careful
consideration. The random data SHOULD originate from a good entropy
source. Large amounts of random data in an AR record is undesirable
and may well be an unnecessary overhead because it increases the
likelihood of truncated responses and an increased use of TCP based
queries.
Reid Expires February 7, 2009 [Page 8]
Internet-Draft Extra Entropy August 2008
6. Security Considerations
It MUST be recognised that this document only provides a limited
defence from DNS forgery attacks. Although it introduces additional
entropy to DNS queries that makes it harder to predict their
contents, this scheme provides no protection whatsoever if an
attacker has visibility of the outgoing query or its response and can
intercept them. The only way to prevent these vulnerabilities is the
use of transaction authentication and/or DNSSEC to detect spoofed or
tampered responses.
The suggested use of AL records is an ugly kludge to essentially
increase the number of bits for a query ID without modifying the core
protocol or breaking the installed base. It is not and MUST NOT be
viewed as a mechanism to either provide DNS transaction security or
authentication. The scheme proposed in this document is intended to
minmise the exposure of routine UDP-based query/response transactions
to forgery attacks that attempt to predict the query ID and port
number. In particular, the introduction of this scheme and AR
records MUST NOT be used to authenticate or validate any forms of
zone transfer or dynamic update. These should be protected by some
combination of transaction signature and secure data transport
mechanisms such as a VPN or IPsec.
Reid Expires February 7, 2009 [Page 9]
Internet-Draft Extra Entropy August 2008
7. IANA Considerations
IANA is requested to issue a new type code and mnemonic for the
proposed resource record. No other IANA services are required by
this document.
Reid Expires February 7, 2009 [Page 10]
Internet-Draft Extra Entropy August 2008
8. Acknowledgements
The author would like to thank the authors of RFC 2845, Paul Vixie,
Olafur Gudmundsson, Donald Eastlake and Brian Wellington for
unintentionally inspiring this draft.
Reid Expires February 7, 2009 [Page 11]
Internet-Draft Extra Entropy August 2008
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
9.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
Reid Expires February 7, 2009 [Page 12]
Internet-Draft Extra Entropy August 2008
Author's Address
Jim Reid
RTFM Ltd
RTFM Ltd.
6 Langside Court
Bothwell
Scotland
Phone: +44 1698 852881
Email: jim@rfc1035.org
Reid Expires February 7, 2009 [Page 13]
Internet-Draft Extra Entropy August 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.
Reid Expires February 7, 2009 [Page 14]
