draft-ietf-dnsext-forgery-resilience-04.txt   draft-ietf-dnsext-forgery-resilience-05.txt 
DNS Extensions (DNSEXT) A. Hubert DNS Extensions (DNSEXT) A. Hubert
Internet-Draft Netherlabs Computer Consulting BV. Internet-Draft Netherlabs Computer Consulting BV.
Updates: 1034 (if approved) R. van Mook Updates: 1034 (if approved) R. van Mook
Intended status: Standards Track Virtu Intended status: Standards Track Virtu
Expires: December 25, 2008 June 23, 2008 Expires: December 28, 2008 June 26, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-04.txt draft-ietf-dnsext-forgery-resilience-05.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 December 25, 2008. This Internet-Draft will expire on December 28, 2008.
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 2, line 28 skipping to change at page 2, line 28
resilient against accepting incorrect responses. This document resilient against accepting incorrect responses. This document
updates RFC 1034. updates RFC 1034.
Table of Contents Table of Contents
1. Requirements and definitions . . . . . . . . . . . . . . . . . 3 1. Requirements and definitions . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6
4. Detailed Description of Spoofing Scnearios . . . . . . . . . . 7 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 7
4.1. Forcing a question . . . . . . . . . . . . . . . . . . . . 7 4.1. Forcing a question . . . . . . . . . . . . . . . . . . . . 7
4.2. Matching the question section . . . . . . . . . . . . . . 8 4.2. Matching the question section . . . . . . . . . . . . . . 8
4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 8 4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 8
4.4. Matching the source address of the authentic response . . 8 4.4. Matching the source address of the authentic response . . 8
4.5. Matching the destination address and port of the 4.5. Matching the destination address and port of the
authentic response . . . . . . . . . . . . . . . . . . . . 8 authentic response . . . . . . . . . . . . . . . . . . . . 8
4.6. Have the response arrive before the authentic response . . 9 4.6. Have the response arrive before the authentic response . . 9
5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10
6. Accepting only in-zone records . . . . . . . . . . . . . . . . 11 6. Accepting only in-zone records . . . . . . . . . . . . . . . . 11
7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 12 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 12
7.1. Symbols used in calculation . . . . . . . . . . . . . . . 12 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 12
7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 13
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Recommended ountermeasures . . . . . . . . . . . . . . . . . . 16 9. Recommended Countermeasures . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Requirements and definitions 1. Requirements and definitions
1.1. Definitions 1.1. Definitions
This document uses the following definitions: This document uses the following definitions:
Client: typically a 'stub-resolver' on an end-user's computer Client: typically a 'stub-resolver' on an end-user's computer
Resolver: a nameserver performing recursive service for clients, Resolver: a nameserver performing recursive service for clients,
also known as a caching server, or a full service resolver also known as a caching server, or a full service resolver
([RFC1123], paragraph 6.1.3.1) ([RFC1123], paragraph 6.1.3.1)
Stub resolver: a very limited Resolver on a client computer, that Stub resolver: a very limited Resolver on a client computer, that
leaves the recursing work to a full resolver leaves the recursing work to a full resolver
Query: a question sent out by a resolver, typically in a UDP Query: a question sent out by a resolver, typically in a UDP
packet packet
Reponse: the answer sent back by an authoritative nameserver, Response: the answer sent back by an authoritative nameserver,
typically in a UDP packet typically in a UDP packet
Third party: any entity other than the resolver or the intended Third party: any entity other than the resolver or the intended
recipient of a question. The third party may have access to an recipient of a question. The third party may have access to an
arbitrary authoritative nameserver, but has no access to packets arbitrary authoritative nameserver, but has no access to packets
transmitted by the Resolver or authoritative server transmitted by the Resolver or authoritative server
Attacker: malicious third party. Attacker: malicious third party.
Spoof: the activity of attempting to subvert the DNS process by Spoof: the activity of attempting to subvert the DNS process by
skipping to change at page 5, line 12 skipping to change at page 5, line 12
This document expands on some of the risks mentioned in RFC 3833, This document expands on some of the risks mentioned in RFC 3833,
especially those outlined in the sections on 'ID Guessing and Query especially those outlined in the sections on 'ID Guessing and Query
Prediction' and 'Name Chaining'. Furthermore, it emphasises a number Prediction' and 'Name Chaining'. Furthermore, it emphasises a number
of existing rules and guidelines embodied in the relevant DNS of existing rules and guidelines embodied in the relevant DNS
protocol specifications. The following also specifies new protocol specifications. The following also specifies new
requirements to make sure the Domain Name System can be relied upon requirements to make sure the Domain Name System can be relied upon
until a more secure protocol has been standardised and deployed. until a more secure protocol has been standardised and deployed.
It should be noted that even when all measures suggested below are It should be noted that even when all measures suggested below are
implemented, protocol users are not protected against third parties implemented, protocol users are not protected against third parties
with the ability to intercept, change or inject packets sent to the with the ability to observe, modify or inject packets in the traffic
resolver. of a resolver.
For protocol extensions under development that offer protection For protocol extensions under development that offer protection
against these scenarios, see [RFC4033] and beyond. against these scenarios, see [RFC4033] and beyond.
3. Description of DNS spoofing 3. Description of DNS spoofing
When certain steps are taken it is feasible to 'spoof' the current When certain steps are taken it is feasible to 'spoof' the current
deployed majority of resolvers with carefully crafted and timed DNS deployed majority of resolvers with carefully crafted and timed DNS
packets. Once spoofed, a caching server will repeat the data it packets. Once spoofed, a caching server will repeat the data it
wrongfully accepted, and make its clients contact the wrong, and wrongfully accepted, and make its clients contact the wrong, and
skipping to change at page 7, line 5 skipping to change at page 7, line 5
If a third party succeeds in meeting the four conditions before the If a third party succeeds in meeting the four conditions before the
response from the authentic nameserver does so, it is in a position response from the authentic nameserver does so, it is in a position
to feed a resolver fabricated data. When it does so, we dub it an to feed a resolver fabricated data. When it does so, we dub it an
attacker, attempting to spoof in fake data. attacker, attempting to spoof in fake data.
All conditions mentioned above can theoretically be met by a third All conditions mentioned above can theoretically be met by a third
party, with the difficulty being a function of the resolver party, with the difficulty being a function of the resolver
implementation and zone configuration. implementation and zone configuration.
4. Detailed Description of Spoofing Scnearios 4. Detailed Description of Spoofing Scenarios
The previous paragraph discussed a number of requirements an attacker The previous paragraph discussed a number of requirements an attacker
must match in order to spoof in manipulated (or fake) data. This must match in order to spoof in manipulated (or fake) data. This
section discusses the relative difficulties and how implementation section discusses the relative difficulties and how implementation
defined choices impact the amount of work an attacker has to perform defined choices impact the amount of work an attacker has to perform
to meet said difficulties. to meet said difficulties.
Some more details can be found in section 2.2 of [RFC3833]. Some more details can be found in section 2.2 of [RFC3833].
4.1. Forcing a question 4.1. Forcing a question
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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.
9. Recommended ountermeasures 9. Recommended Countermeasures
Given the above, a resolver implementation MUST match responses to Given the above, a resolver implementation MUST match responses to
the following attributes of the query: the following attributes of the query:
o Remote address o Remote address
o Local address o Local address
o Query port o Query port
skipping to change at page 17, line 11 skipping to change at page 17, line 11
and receive datagrams using more than one IP source address, then an and receive datagrams using more than one IP source address, then an
IP address can be chosen at random in order to increase an attacker's IP address can be chosen at random in order to increase an attacker's
difficulty in guessing what address to flood. difficulty in guessing what address to flood.
If a resolver sends out multiple equivalent queries to any If a resolver sends out multiple equivalent queries to any
authoritative server, before receiving a response, all MUST have authoritative server, before receiving a response, all MUST have
identical ID, source address and source port. identical ID, source address and source port.
Resolvers SHOULD favour authoritative nameservers with which a trust Resolvers SHOULD favour authoritative nameservers with which a trust
relation has been established; Stub-resolvers SHOULD be able to use relation has been established; Stub-resolvers SHOULD be able to use
TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their
recursive resolver. recursive resolver.
In case a cryptographic verification of response validity is In case a cryptographic verification of response validity is
available, resolver implementations MAY waive above rules, and rely available, resolver implementations MAY waive above rules, and rely
on this guarantee instead. on this guarantee instead.
Proper unpredictability can be achieved by employing a high quality Proper unpredictability can be achieved by employing a high quality
random generator, as described in [RFC4086]. random generator, as described in [RFC4086].
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 18, line 11 skipping to change at page 18, line 11
outlined above, it MAY abandon the UDP query and re-issue it over outlined above, it MAY abandon the UDP query and re-issue it over
TCP. TCP, by the nature of its use of sequence numbers, is far more TCP. TCP, by the nature of its use of sequence numbers, is far more
resilient against forgery by third parties. resilient against forgery by third parties.
10. Security Considerations 10. Security Considerations
This document provides clarification of the DNS specification to This document provides clarification of the DNS specification to
decrease the probability that DNS responses can be successfully decrease the probability that DNS responses can be successfully
forged. Recommendations found above should be considered forged. Recommendations found above should be considered
complementary to possible cryptographical enhancements of the domain complementary to possible cryptographical enhancements of the domain
name system. name system, which protect against a larger class of attacks.
This document recommends the use of UDP source port number This document recommends the use of UDP source port number
randomization to extend the effective DNS transaction ID beyond the randomization to extend the effective DNS transaction ID beyond the
available 16 bits. available 16 bits.
A resolver that does not implement the recommendations outlined above A resolver that does not implement the recommendations outlined above
can easily be forced to accept spoofed responses, which in turn are can easily be forced to accept spoofed responses, which in turn are
passed on to client computers - misdirecting (user) traffic to passed on to client computers - misdirecting (user) traffic to
possibly malicious entities. possibly malicious entities.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 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 To Live for DNS records raises the chances of an attacker spoofing a
resolver. resolver.
11. Acknowledgements 11. IANA Considerations
This document does not make any assignments and has no actions for
IANA.
12. Acknowledgements
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,
Peter Koch,
Sean Leach, Sean Leach,
Norbert Sendetzky, Norbert Sendetzky,
Paul Vixie, Paul Vixie,
Florian Weimer, Florian Weimer,
Wouter Wijngaards, Wouter Wijngaards,
Dan Wing Dan Wing
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 20, line 46 skipping to change at page 21, line 46
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
12.2. Informative References 13.2. Informative References
[I-D.ietf-dnsop-reflectors-are-evil] [I-D.ietf-dnsop-reflectors-are-evil]
Damas, J. and F. Neves, "Preventing Use of Recursive Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", Nameservers in Reflector Attacks",
draft-ietf-dnsop-reflectors-are-evil-05 (work in draft-ietf-dnsop-reflectors-are-evil-05 (work in
progress), December 2007. progress), December 2007.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 4301, December 2005.
[vu-457875] [vu-457875]
United States CERT, "Various DNS service implementations United States CERT, "Various DNS service implementations
generate multiple simultaneous queries for the same generate multiple simultaneous queries for the same
resource record", VU 457875, November 2002. resource record", VU 457875, November 2002.
Authors' Addresses Authors' Addresses
bert hubert bert hubert
Netherlabs Computer Consulting BV. Netherlabs Computer Consulting BV.
 End of changes. 18 change blocks. 
24 lines changed or deleted 32 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/