draft-ietf-dnsext-forgery-resilience-06.txt   draft-ietf-dnsext-forgery-resilience-07.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: January 31, 2009 July 30, 2008 Expires: February 15, 2009 August 14, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-06.txt draft-ietf-dnsext-forgery-resilience-07.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 January 31, 2009. This Internet-Draft will expire on February 15, 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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
4.4. Matching the source address of the authentic response . . 9 4.4. Matching the source address of the authentic response . . 9
4.5. Matching the destination address and port of the 4.5. Matching the destination address and port of the
authentic response . . . . . . . . . . . . . . . . . . . . 9 authentic response . . . . . . . . . . . . . . . . . . . . 9
4.6. Have the response arrive before the authentic response . . 10 4.6. Have the response arrive before the authentic response . . 10
5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 11 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 11
6. Accepting only in-domain records . . . . . . . . . . . . . . . 12 6. Accepting only in-domain records . . . . . . . . . . . . . . . 12
7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 13 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 13
7.1. Symbols used in calculation . . . . . . . . . . . . . . . 13 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 13
7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 14
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Repetitive spoofing attempts for a single domain name . . 16
9. Forgery countermeasures . . . . . . . . . . . . . . . . . . . 17 9. Forgery countermeasures . . . . . . . . . . . . . . . . . . . 17
9.1. Query matching rules . . . . . . . . . . . . . . . . . . . 17 9.1. Query matching rules . . . . . . . . . . . . . . . . . . . 17
9.2. Extending the Q-ID space by using ports and addresses . . 17 9.2. Extending the Q-ID space by using ports and addresses . . 17
9.2.1. Justification and Discussion . . . . . . . . . . . . . 18 9.2.1. Justification and Discussion . . . . . . . . . . . . . 18
9.3. Spoof detection and countermeasure . . . . . . . . . . . . 18 9.3. Spoof detection and countermeasure . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Requirements and definitions 1. Requirements and definitions
1.1. Definitions 1.1. Definitions
skipping to change at page 16, line 5 skipping to change at page 15, line 30
From this formula it can be seen that, if the nameserver From this formula it can be seen that, if the nameserver
implementation is unchanged, only raising the TTL offers protection. implementation is unchanged, only raising the TTL offers protection.
Raising N, the number of authoritative nameservers, is not feasible Raising N, the number of authoritative nameservers, is not feasible
beyond a small number. beyond a small number.
For the degenerate case of a zero-second TTL, a window of opportunity For the degenerate case of a zero-second TTL, a window of opportunity
opens for each query sent, making the effective TTL equal to 'W' opens for each query sent, making the effective TTL equal to 'W'
above, the response time of the authoritative server. above, the response time of the authoritative server.
This last case also holds for spoofing techniques which do not rely
on TTL expiry, but use repeated and changing queries.
8. Discussion 8. Discussion
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.
skipping to change at page 17, line 5 skipping to change at page 16, line 33
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.
Such bandwidth is not generally available, nor expected to be so in Such bandwidth is not generally available, nor expected to be so in
the foreseeable future. the foreseeable future.
Note that some firewalls may need reconfiguring if they are currently Note that some firewalls may need reconfiguring if they are currently
setup to only allow outgoing queries from a single DNS source port. setup to only allow outgoing queries from a single DNS source port.
8.1. Repetitive spoofing attempts for a single domain name
Techniques are available to use an effectively infinite number of
queries to achieve a desired spoofing goal. In the math above, this
reduces the effective TTL to 0.
If such techniques are employed, using the same 7000 packets/s rate
mentioned above, and using 1 source port, the spoofing chance rises
to 50% within 7 seconds.
If 64000 ports are used, as recommended in this document, using the
same query rate, the 50% level is reached after around 116 hours.
9. Forgery countermeasures 9. Forgery countermeasures
9.1. Query matching rules 9.1. Query matching rules
A resolver implementation MUST match responses to all of the A resolver implementation MUST match responses to all of the
following attributes of the query: following attributes of the query:
o Source address against query destination address o Source address against query destination address
o Destination address against query source address o Destination address against query source address
skipping to change at page 18, line 23 skipping to change at page 18, line 23
held by such a resolver can be measured, and it must not be trivially held by such a resolver can be measured, and it must not be trivially
easy to reverse engineer the resolver's internal state in a way that easy to reverse engineer the resolver's internal state in a way that
allows low-cost high-accuracy prediction of future state. allows low-cost high-accuracy prediction of future state.
A full DNS resolver with only one or a small number of upstream- A full DNS resolver with only one or a small number of upstream-
facing endpoints is effectively using constants for IP source address facing endpoints is effectively using constants for IP source address
and UDP port number, and these are very predictable by potential and UDP port number, and these are very predictable by potential
attackers, and must therefore be avoided. attackers, and must therefore be avoided.
A full DNS resolver that uses a simple increment to get its next DNS A full DNS resolver that uses a simple increment to get its next DNS
ID is likewise very predictable and so very spoofable. query ID is likewise very predictable and so very spoofable.
Finally, weak random number generators have been shown to expose Finally, weak random number generators have been shown to expose
their internal state, such that an attacker who witnesses several their internal state, such that an attacker who witnesses several
sequential "random" values can easily predict the next ones. A sequential "random" values can easily predict the next ones. A
crypto-strength random number generator is one whose output cannot be crypto-strength random number generator is one whose output cannot be
predicted no matter how many successive values are witnessed. predicted no matter how many successive values are witnessed.
9.3. Spoof detection and countermeasure 9.3. Spoof detection and countermeasure
If a resolver detects that an attempt is being made to spoof it, If a resolver detects that an attempt is being made to spoof it,
skipping to change at page 21, line 5 skipping to change at page 21, line 5
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. Acknowledgements 12. Acknowledgments
Source port randomisation in DNS was first implemented and possibly Source port randomisation in DNS was first implemented and possibly
invented by Dan. J. Bernstein. invented by Dan. J. Bernstein.
Although any mistakes remain our own, the authors gratefully Although any mistakes remain our own, the authors gratefully
acknowledge the help and contributions of: acknowledge the help and contributions of:
Stephane Bortzmeyer, Stephane Bortzmeyer,
Alfred Hoenes, Alfred Hoenes,
 End of changes. 9 change blocks. 
6 lines changed or deleted 23 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/