One document matched: draft-barwood-dnsext-fr-resolver-mitigations-00.txt
DNS Extensions Working Group G. Barwood
Internet-Draft
Intended status: Informational September 5, 2008
Expires: March 2009
Resolver side mitigations
draft-barwood-dnsext-fr-resolver-mitigations-00
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 in March 2009 .
Abstract
Describes mitigations against spoofing attacks on DNS.
Barwood Expires March 2009 [Page 1]
Internet-Draft Resolver mitigations August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Prepend a random nonce label to the question. . . . . . . 4
3.2. Repeat the query . . . . . . . . . . . . . . . . . . . . 6
3.3 Include Bad IDs in entropy caclulation . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . . 10
Barwood Expires March 2009 [Page 2]
Internet-Draft Resolver mitigations August 2008
1. Introduction
This document describes mitigations that a resolver can currently
deploy to resist spoofing attacks on DNS, without server software
being updated.
2. Criteria
These are resolver side solutions, thus only the resolver needs to be
redeployed, or the software updated, for this to work. This allows
deployment in the short term.
The solutions have to follow the DNS protocol.
The solutions have to be practical, non disruptive, and not anti-social.
The context in which these solutions were explored is CERT Vulnerability Note VU#800113, "Multiple DNS implementations vulnerable to cache poisoning".
Barwood Expires March 2009 [Page 3]
Internet-Draft Resolver mitigations August 2008
3. Mitigations
Below, the resolver side mitigations are described.
Not described are port randomization, and 0x20 ( which are both
nevertheless recommmended ). The techniques are especially, but not
solely applicable where port randomization is not possible, due
to NAT devices or other reasons.
3.1. Prepend a random nonce label to the question.
This should be used where a referral is probable.
It allows an amount of entropy to be encoded limited only by the 256
character limit on a question, provided the authority server returns a
copy of the question in the response.
If the response is a Name Error (due tio the server being authoritative
for the question), or an Answer is given ( due to a wildcard ), the
response should be discarded, and the query repeated without the nonce.
A simple heuristic for deciding where a referral probable is:
(1) If the Bailiwick is Root, and the last label in the question is
a known TLD other than ARPA, a referral is probable.
Barwood Expires March 2009 [Page 4]
Internet-Draft Resolver mitigations August 2008
(2) If the Bailiwick is top level ( does not have a dot ), a referral
is probable.
(3) Otherwise a referral is not probable.
Where the heuristic fails, this may be recorded so subsequent retries
are avoided.
A static list of known TLDs (and any exceptional cases) may be kept. If
this list is not up to date, extra queries may be generated, but no loss
of functionality will occur.
Barwood Expires March 2009 [Page 5]
Internet-Draft Resolver mitigations August 2008
3.2. Query repetition
By repeating the query, additional entropy may be obtained. A practical
problem occurs when responses are non-deterministic, that is many
different responses are obtained for the same question.
In this case, the resolver will need to perform an analysis to produce
a converged result.
RFC 2181 introduced the concept of "RRset Integrity", and this needs
to be taken into account.
Resolvers may decide to ditch RRset Integrity for some Types, for
non-deterministic servers, if the alternative is unacceptable security
or failure to resolve a name.
In particular, for most of the types defined in RFC 1034/1035, RRset
integrity may not be essential.
One model is to accumulate entropy for various attributes of each
observed RRset, such as Number of values, Value, TTL. Provided these
converge, a plausible synthesised RRset may be constructed.
For example, suppose the question is MX records for example.com.
First response:
example.com MX mail1.example.com
example.com MX mail2.example.com
Second response:
example.com MX mail2.example.com ( mail2.example.com confirmed)
example.com MX mail3.example.com
Barwood Expires March 2009 [Page 6]
Internet-Draft Resolver mitigations August 2008
Third response:
example.com MX mail3.example.com ( mail3.example.com confirmed )
example.com MX mail4.example.com
Plausible result:
example.com MX mail2.example.com
example.com MX mail3.example.com
The semantic model here is that 2 MX records are to be offered,
but the selection does not matter.
Another possibility where convergence is slow is to resolve glue. For
example:
First response:
example.com NS ns1.example.com
example.com NS ns2.example.com
..
example.com NS ns9.example.com
ns1.example.com A 0.0.0.1
ns2.example.com A 0.0.0.2
..
ns9.example.com A 0.0.0.9
Second response:
example.com NS ns1.example.com
example.com NS ns2.example.com
..
example.com NS ns9.example.com
ns1.example.com A 0.0.0.2
ns2.example.com A 0.0.0.3
..
ns8.example.com A 0.0.0.9
ns9.example.com A 0.0.0.1
Converged result:
example.com NSA 0.0.0.1
example.com NSA 0.0.0.2
..
example.com NSA 0.0.0.9
where NSA is an internal pseudo-type with the obvious meaning.
Some in-essential information is lost, but resolution can
still proceed.
This may all sound quite daunting, but early practical experiments
show that commonly encountered non-deterministic servers select values
from very small pools (in short time intervals), and show simple behavior.
A more comprehensive survey of such servers would be valuable,
unfortunately the author does not have access to the resources
needed to carry out such a survey properly.
Barwood Expires March 2009 [Page 7]
Internet-Draft Resolver mitigations August 2008
3.3. Include observed Bad IDs in entropy calculation
When a response is received, an entropy calculation may be performed
to estimate how many bits have been checked.
It will typically include the 0x20 bits, the prepended nonce,
16 bits for the ID, and discount for unusual/non-standard
features ( such as IP mismatch, question not copied ).
The number of incorrect IDs observed while waiting for a response
should be included in the calculation, for example the logarithm
(base 2) of the number of Bad IDs could be subtracted.
The result of the calculation should be used to decide whether to
repeat the query. This allows a smooth response to attacks, while
not detracting from performance in the normal situation where Bad
IDs are not observed.
While this measure does not reduce the number of packets required
for a successful attack, it does increase the time required, since
an attacker gains nothing from sending spoof packets at a very
high rate.
Barwood Expires March 2009 [Page 8]
Internet-Draft Resolver mitigations August 2008
5. Security Considerations
All of the mitigations aim to provide more security. Query repetition
has an obvious adverse effect on performance and bandwith.
Each query repetition provides an extra attack opportunity, so the
total entropy requirement may be adjusted to reflect this.
The random nonce may expose internal state to an attacker who
controls a name server. It is essential that a cryptographically
strong source of random numbers be used to generate IDs, 0x20 bits
and prepended nonces. This must be seeded from data that cannot be
guessed by an attacker, such as thermal noise or other random
physical fluctuations.
A sufficently determined attacker may cause a denial of service, due to
a very large number of Bad IDs reducing the effective entropy to zero.
In practice, denial of service would probably occur due to the extreme
number of incoming packets.
6. IANA Considerations
None.
Barwood Expires March 2009 [Page 9]
Internet-Draft Resolver mitigations August 2008
7. Acknowledgments
Thanks to Nicholas Weaver (ICSI Berkeley) and Wouter Wijngaards (NLnet
Labs). The idea of prepending a nonce may be due to Paul Vixie (ISC).
8. Informative References
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
Author's Address
George Barwood
33 Sandpiper Close
Gloucester GL2 4LZ
United Kingdom
Phone: +44 452 722670
EMail: george.barwood@blueyonder.co.uk
Skype: george.barwood
Barwood Expires March 2009 [Page 10]
Internet-Draft Resolver mitigations 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.
Barwood Expires March 2009 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:02:48 |