draft-ietf-dnsext-forgery-resilience-07.txt   draft-ietf-dnsext-forgery-resilience-08.txt 
DNS Extensions (DNSEXT) A. Hubert DNS Extensions (DNSEXT) A. Hubert
Internet-Draft Netherlabs Computer Consulting BV. Internet-Draft Netherlabs Computer Consulting BV.
Updates: 2181 (if approved) R. van Mook Updates: 2181 (if approved) R. van Mook
Intended status: Standards Track Equinix Intended status: Standards Track Equinix
Expires: February 15, 2009 August 14, 2008 Expires: May 21, 2009 November 17, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-07.txt draft-ietf-dnsext-forgery-resilience-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 15, 2009. This Internet-Draft will expire on May 21, 2009.
Abstract Abstract
The current Internet climate poses serious threats to the Domain Name The current Internet climate poses serious threats to the Domain Name
System. In the interim period before the DNS protocol can be secured System. In the interim period before the DNS protocol can be secured
more fully, measures can already be taken to harden the DNS to make more fully, measures can already be taken to harden the DNS to make
'spoofing' a recursing nameserver many orders of magnitude harder. 'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability Even a cryptographically secured DNS benefits from having the ability
to discard bogus responses quickly, as this potentially saves large to discard bogus responses quickly, as this potentially saves large
amounts of computation. amounts of computation.
By describing certain behaviour that has previously not been By describing certain behaviour that has previously not been
standardised, this document sets out how to make the DNS more standardised, this document sets out how to make the DNS more
resilient against accepting incorrect responses. This document resilient against accepting incorrect responses. This document
updates RFC 1034. updates RFC 2128.
Table of Contents Table of Contents
1. Requirements and definitions . . . . . . . . . . . . . . . . . 4 1. Requirements and definitions . . . . . . . . . . . . . . . . . 4
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 7 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 7
4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 8 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 8
4.1. Forcing a query . . . . . . . . . . . . . . . . . . . . . 8 4.1. Forcing a query . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 16, line 16 skipping to change at page 16, line 16
The calculations above indicate the relative ease with which DNS data The calculations above indicate the relative ease with which DNS data
can be spoofed. For example, using the formula derived earlier on an can be spoofed. For example, using the formula derived earlier on an
RRSet with a 3600 second TTL, an attacker sending 7000 fake response RRSet with a 3600 second TTL, an attacker sending 7000 fake response
packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a
record in the first 24 hours, which rises to 50% after a week. record in the first 24 hours, which rises to 50% after a week.
For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24
minutes, 50% after less than 3 hours, 90% after around 9 hours. minutes, 50% after less than 3 hours, 90% after around 9 hours.
For some classes of attacks, the effective TTL is near zero, as noted
above.
Note that the attacks mentioned above can be detected by watchful Note that the attacks mentioned above can be detected by watchful
server operators - an unexpected incoming stream of 4.5mbit/s of server operators - an unexpected incoming stream of 4.5mbit/s of
packets might be noticed. packets might be noticed.
An important assumption however in these calculations is a known or An important assumption however in these calculations is a known or
static destination port of the authentic response. static destination port of the authentic response.
If that port number is unknown and needs to be guessed as well, the If that port number is unknown and needs to be guessed as well, the
problem space expands by a factor of 64000, leading the attacker to problem space expands by a factor of 64000, leading the attacker to
need in excess of 285Gb/s to achieve similar success rates. need in excess of 285Gb/s to achieve similar success rates.
skipping to change at page 19, line 35 skipping to change at page 19, line 35
Most security considerations can be found in Section 4 and Section 5, Most security considerations can be found in Section 4 and Section 5,
while proposed countermeasures are described in Section 9. while proposed countermeasures are described in Section 9.
For brevity's sake, in lieu of repeating the security considerations For brevity's sake, in lieu of repeating the security considerations
references, the reader is referred to these sections. references, the reader is referred to these sections.
Nothing in this document specifies specific algorithms for operators Nothing in this document specifies specific algorithms for operators
to use; it does specify algorithms implementations SHOULD or MUST to use; it does specify algorithms implementations SHOULD or MUST
support. support.
The above notwithstanding, it should be noted that using a low Time
To Live for DNS records raises the chances of an attacker spoofing a
resolver.
It should be noted that the effects of source port randomization may It should be noted that the effects of source port randomization may
be dramatically reduced by NAT devices which either serialize or be dramatically reduced by NAT devices which either serialize or
limit in volume the UDP source ports used by the querying resolver." limit in volume the UDP source ports used by the querying resolver."
11. IANA Considerations 11. IANA Considerations
This document does not make any assignments and has no actions for This document does not make any assignments and has no actions for
IANA. IANA.
12. Acknowledgments 12. Acknowledgments
 End of changes. 6 change blocks. 
8 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/