draft-ietf-dnsext-forgery-resilience-02.txt   draft-ietf-dnsext-forgery-resilience-03.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: August 22, 2008 February 19, 2008 Expires: September 25, 2008 March 24, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-02.txt draft-ietf-dnsext-forgery-resilience-03.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 August 22, 2008. This Internet-Draft will expire on September 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
RFC 1034. 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. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Matching the question . . . . . . . . . . . . . . . . . . 7 4.1. Forcing a question . . . . . . . . . . . . . . . . . . . . 7
4.2. Matching the ID field . . . . . . . . . . . . . . . . . . 8 4.2. Matching the question section . . . . . . . . . . . . . . 8
4.3. Matching the source address of the authentic answer . . . 8 4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 8
4.4. Matching the destination address of the authentic 4.4. Matching the source address of the authentic answer . . . 8
4.5. Matching the destination address of the authentic
answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Have the answer arrive before the authentic answer . . . . 9 4.6. Have the answer arrive before the authentic answer . . . . 9
5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10
6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 11 6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 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. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 9. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Normative References . . . . . . . . . . . . . . . . . . . . . 19 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22
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,
skipping to change at page 4, line 43 skipping to change at page 4, line 43
It is entirely conceivable that such rerouted traffic could be used It is entirely conceivable that such rerouted traffic could be used
to the disadvantage of Internet users. to the disadvantage of Internet users.
These and other developments have made the security and These and other developments have made the security and
trustworthiness of DNS of renewed importance. Although the DNS trustworthiness of DNS of renewed importance. Although the DNS
community is working hard on finalising and implementing a community is working hard on finalising and implementing a
cryptographically enhanced DNS protocol, steps should be taken to cryptographically enhanced DNS protocol, steps should be taken to
make sure that the existing use of DNS is as secure as possible make sure that the existing use of DNS is as secure as possible
within the bounds of the relevant standards. within the bounds of the relevant standards.
It should be noted that the most commonly used resolver currently It should be noted that the most commonly used resolvers currently do
does not perform as well as possible in this respect, making this not perform as well as possible in this respect, making this document
document of urgent importance. of urgent importance.
A thorough analysis of risks facing DNS can be found in [RFC3833]. A thorough analysis of risks facing DNS can be found in [RFC3833].
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 STDs and of existing rules and guidelines embodied in the relevant STDs and
RFCs. The following also specifies new requirements to make sure the RFCs. The following also specifies new requirements to make sure the
Domain Name System can be relied upon until a more secure protocol Domain Name System can be relied upon until a more secure protocol
has been standardised and deployed. has been standardised and deployed.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
makes a resolver (and more specifically a caching server) accept an makes a resolver (and more specifically a caching server) accept an
answer. answer.
The following sentence in section 5.3.3 of [RFC1034] presaged the The following sentence in section 5.3.3 of [RFC1034] presaged the
present problem: present problem:
The resolver should be highly paranoid in its parsing of responses. The resolver should be highly paranoid in its parsing of responses.
It should also check that the response matches the query it sent It should also check that the response matches the query it sent
using the ID field in the response. using the ID field in the response.
DNS data is accepted by a resolver if and only if: DNS data is to be accepted by a resolver if and only if:
1. The question section of the reply packet is identical to that of 1. The question section of the reply packet is equivalent to that of
a question packet currently waiting for an answer a question packet currently waiting for an answer
2. The ID field of the reply packet matches that of the question 2. The ID field of the reply packet matches that of the question
packet packet
3. The answer comes from the same network address the question was 3. The answer comes from the same network address the question was
sent to sent to
4. The answer comes in on the same network address, including port 4. The answer comes in on the same network address, including port
number, as the question was sent from number, as the question was sent from
5. It is the first answer to match the previous four conditions. In general, the first answer matching these four conditions is
accepted.
If a third party succeeds in meeting the first four conditions before If a third party succeeds in meeting the four conditions before the
the answer from the authentic answer does so, it is in a position to answer from the authentic answer does so, it is in a position to feed
feed a resolver fabricated data. When it does so, we dub it an a resolver fabricated data. When it does so, we dub it an attacker,
attacker, attempting to spoof in fake data. attempting to spoof in fake data.
All conditions mentioned above can theoretically be met, with the All conditions mentioned above can theoretically be met by a third
difficulty being a function of the resolver implementation and zone party, with the difficulty being a function of the resolver
configuration. implementation and zone configuration.
4. Details 4. Details
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. Matching the question 4.1. Forcing a question
Formally, there is no need for a nameserver to perform service except Formally, there is no need for a nameserver to perform service except
for its operator, its customers or more generally its users. for its operator, its customers or more generally its users.
Recently, open recursing nameservers have been used to amplify denial Recently, open recursing nameservers have been used to amplify denial
of service attacks. of service attacks.
In spite of this, many resolvers perform at least partial service for In spite of this, many resolvers perform at least partial service for
the whole world. This is partially out of lack of concern, and is the whole world. This is partially out of lack of concern, and is
reminiscent of the open relay SMTP service the net enjoyed up to the reminiscent of the open relay SMTP service the net enjoyed up to the
early 1990s. Some access providers may serve so many subnets that it early 1990s. Some access providers may serve so many subnets that it
skipping to change at page 8, line 5 skipping to change at page 8, line 5
to refresh the expired entry. to refresh the expired entry.
The time to live of the 'target domain' determines how often a window The time to live of the 'target domain' determines how often a window
of opportunity is available, which implies that a short TTL makes of opportunity is available, which implies that a short TTL makes
spoofing far more viable. spoofing far more viable.
Note that the attacker might very well have authorised access to the Note that the attacker might very well have authorised access to the
target resolver by virtue of being a customer or employee of its target resolver by virtue of being a customer or employee of its
operator. operator.
4.2. Matching the ID field 4.2. Matching the question section
DNS packets, both queries and answers, contain a question section.
Incoming answers should be verified to have a question section that
is equivalent to that of the outgoing query.
4.3. Matching the ID field
The DNS ID field is 16 bits wide, meaning that if full use is made of The DNS ID field is 16 bits wide, meaning that if full use is made of
all these bits, and if their contents are truly random, it will all these bits, and if their contents are truly random, it will
require on average 32768 attempts to guess. Anecdotal evidence require on average 32768 attempts to guess. Anecdotal evidence
suggests there are implementations utilising only 14 bits, meaning on suggests there are implementations utilising only 14 bits, meaning on
average 8192 attempts will suffice. average 8192 attempts will suffice.
Additionally, if the target nameserver can be forced into having Additionally, if the target nameserver can be forced into having
multiple identical questions outstanding, the 'Birthday Attack' multiple identical questions outstanding, the 'Birthday Attack'
phenomenon means that any fake data sent by the attacker is matched phenomenon means that any fake data sent by the attacker is matched
against multiple outstanding questions, significantly raising the against multiple outstanding questions, significantly raising the
chance of success. Further details in Section 5. chance of success. Further details in Section 5.
4.3. Matching the source address of the authentic answer 4.4. Matching the source address of the authentic answer
Most domains have two or three authoritative nameservers, which make Most domains have two or three authoritative nameservers, which make
matching the source address of the authentic answer very likely with matching the source address of the authentic answer very likely with
even a naive choice having a double digit success rate. even a naive choice having a double digit success rate.
Most recursing nameservers store relative performance indications of Most recursing nameservers store relative performance indications of
authoritative nameservers, which may make it easier to predict which authoritative nameservers, which may make it easier to predict which
nameserver would originally be queried - the one most likely to nameserver would originally be queried - the one most likely to
respond the quickest. respond the quickest.
skipping to change at page 8, line 41 skipping to change at page 8, line 47
before it is matched. before it is matched.
It should be noted that meeting this condition entails being able to It should be noted that meeting this condition entails being able to
transmit packets on behalf of the address of the authoritative transmit packets on behalf of the address of the authoritative
nameserver. While two Best Current Practice documents ([RFC2827] and nameserver. While two Best Current Practice documents ([RFC2827] and
[RFC3013] specifically) direct Internet access providers to prevent [RFC3013] specifically) direct Internet access providers to prevent
their customers from assuming IP addresses that are not assigned to their customers from assuming IP addresses that are not assigned to
them, these recommendations are not universally (nor even widely) them, these recommendations are not universally (nor even widely)
implemented. implemented.
4.4. Matching the destination address of the authentic answer 4.5. Matching the destination address of the authentic answer
Note that the destination address of the authentic answer is the Note that the destination address of the authentic answer is the
source address of the original question. source address of the original question.
The actual address of a recursing nameserver is generally known; the The actual address of a recursing nameserver is generally known; the
port used for asking questions is harder to determine. Most current port used for asking questions is harder to determine. Most current
resolvers pick a random port at startup and use this for all outgoing resolvers pick an arbitrary port at startup (possibly at random) and
questions. In quite a number of cases the source port of outgoing use this for all outgoing questions. In quite a number of cases the
questions is fixed at the traditional DNS assigned server port number source port of outgoing questions is fixed at the traditional DNS
of 53. assigned server port number of 53.
If the source port of the original question is random, but static, If the source port of the original question is random, but static,
any authoritative nameserver under observation by the attacker can be any authoritative nameserver under observation by the attacker can be
used to determine this port. This means that matching this used to determine this port. This means that matching this
conditions often requires no guess work. conditions often requires no guess work.
If multiple ports are used for sending questions, this enlarges the If multiple ports are used for sending questions, this enlarges the
effective address space by a factor equal to the number of ports effective address space by a factor equal to the number of ports
used. used.
skipping to change at page 9, line 27 skipping to change at page 9, line 32
If the maximum ports range is utilized, on average, around 32128 If the maximum ports range is utilized, on average, around 32128
source ports would have to be tried before matching the source port source ports would have to be tried before matching the source port
of the original question as ports below 1024 may be unavailable for of the original question as ports below 1024 may be unavailable for
use, leaving 64512 options. use, leaving 64512 options.
It should be noted that a firewall will not prevent the matching of It should be noted that a firewall will not prevent the matching of
this address, as it will accept answers that (appear) to come from this address, as it will accept answers that (appear) to come from
the correct address, offering no additional security. the correct address, offering no additional security.
4.5. Have the answer arrive before the authentic answer 4.6. Have the answer arrive before the authentic answer
Once any packet has matched the previous four conditions, no further Once any packet has matched the previous four conditions (plus
answers should be accepted. possible additional conditions), no further answers are generally
accepted.
This means that the third party has a limited time in which to inject This means that the third party has a limited time in which to inject
its spoofed answer, typically in the order of at most 100ms. its spoofed answer, typically in the order of at most 100ms
(depending on the network distance to the authentic authoritative
nameserver).
This time period can be far longer if the authentic authoritative This time period can be far longer if the authentic authoritative
nameservers are (briefly) overloaded by queries, perhaps by the nameservers are (briefly) overloaded by queries, perhaps by the
attacker. attacker.
5. Birthday attacks 5. Birthday attacks
The so called birthday paradox means that a group of 22 people The so called birthday paradox implies that a group of 23 people
suffices to have a more than even chance of having two or more suffices to have a more than even chance of having two or more
members of the group share a birthday. members of the group share a birthday.
An attacker can benefit from this exact phenomenon if it can force An attacker can benefit from this exact phenomenon if it can force
the target resolver to have multiple outstanding questions at any one the target resolver to have multiple equivalent outstanding questions
time for the same domain to the same authoritative server. at any one time to the same authoritative server.
Any packet the attacker sends then has a much higher chance of being Any packet the attacker sends then has a much higher chance of being
accepted because it only has to match any of the outstanding queries accepted because it only has to match any of the outstanding queries
for that single domain. Compared to the birthday analogy above, of for that single domain. Compared to the birthday analogy above, of
the group composed of questions and answers, the chance of having any the group composed of questions and answers, the chance of having any
of these share an ID rises quickly. of these share an ID rises quickly.
As long as small numbers of questions are sent out, the chance of As long as small numbers of questions are sent out, the chance of
successfully spoofing an answer rises linearly with the number of successfully spoofing an answer rises linearly with the number of
outstanding questions for the exact domain and nameserver. outstanding questions for the exact domain and nameserver.
skipping to change at page 16, line 18 skipping to change at page 16, line 18
following attributes of the question: following attributes of the question:
o Remote address o Remote address
o Local address o Local address
o Query port o Query port
o Query ID o Query ID
o Question (name and type) o Question name (compared case-insensitively)
before applying DNS trustworthiness rules. o Question class and type
Additionally, resolver implementations MUST have the ability to: before applying DNS trustworthiness rules. A mismatch should be
considered a format error, and the answer invalid.
Resolver implementations MUST have the ability to:
o Use an unpredictable source port for outgoing queries from a range o Use an unpredictable source port for outgoing queries from a range
(53, or > 1024) of ports that is as large as possible; (53, or > 1024) of ports that is as large as possible and
practicable;
o Use multiple different source ports simultaneously in case of o Use multiple different source ports simultaneously in case of
multiple outstanding questions; multiple outstanding questions;
o Use an unpredictable query ID for outgoing queries, utilizing the o Use an unpredictable query ID for outgoing queries, utilizing the
full range available (0-65535); full range available (0-65535);
o Assure that its choices of port and ID cannot be predicted by an In case these abilities are enabled, the implementation MUST strive
attacker having knowledge of its (pseudo-)random generator. to have its choices of source port and question ID remain
unpredictable, even if an attacker has knowledge of its
(pseudo-)random generator.
If a resolver is multihomed or otherwise has the ability to transmit
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
difficulty in guessing what address to flood.
If a resolver sends out multiple equivalent questions to any If a resolver sends out multiple equivalent questions to any
authoritative server, before receiving an answer, all MUST have authoritative server, before receiving an answer, 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 ([RFC2401]) when communicating with their
recursive resolver. recursive resolver.
In case a cryptographic verification of answer validity is available,
resolver implementations MAY waive above rules, and rely 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].
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 answers can be successfully forged. decrease the probability that DNS answers can be successfully forged.
Recommendations found above should be considered complementary to Recommendations found above should be considered complementary to
possible cryptographical enhancements of the domain name system. possible cryptographical enhancements of the domain name system.
skipping to change at page 18, line 21 skipping to change at page 19, line 21
acknowledge the help and contributions of: acknowledge the help and contributions of:
Stephane Bortzmeyer, Stephane Bortzmeyer,
Alfred Hoenes, Alfred Hoenes,
Sean Leach, Sean Leach,
Norbert Sendetzky, Norbert Sendetzky,
Paul Vixie,
Florian Weimer, Florian Weimer,
Wouter Wijngaards,
Dan Wing Dan Wing
12. Normative References 12. 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.
 End of changes. 30 change blocks. 
47 lines changed or deleted 77 lines changed or added

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