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.

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
2.  Introduction
3.  AL RR Format
4.  Protocol Operation
    4.1.  Query Generation
    4.2.  Server Processing
    4.3.  Client Processing of Responses
    4.4.  Other applications of the AR Record Type
5.  Operational Considerations
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Introduction

The core DNS protocol is defined in RFC1034[RFC1034] (Mockapetris, P., “DOMAIN NAMES - CONCEPTS AND FACILITIES,” November 1987.), RFC1035[RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) and clarified in RFC2181[RFC2181] (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.). 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] (Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, “Secret Key Transaction Authentication for DNS (TSIG),” May 2000.) and Secure DNS (DNSSEC) RFC4033[RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) RFC4034[RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) RFC4037[RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.). 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.

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

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.

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.

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.

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.

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.

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.

9.  References

9.1. Normative References

9.2. Informative References

Author's Address

Full Copyright Statement

Copyright © 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.