< draft-ietf-dnsext-forgery-resilience-09.txt   draft-ietf-dnsext-forgery-resilience-10.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: May 22, 2009 November 18, 2008 Expires: June 18, 2009 December 15, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-09.txt draft-ietf-dnsext-forgery-resilience-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 22, 2009. This Internet-Draft will expire on June 18, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 20 skipping to change at page 3, line 20
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
4.2. Matching the question section . . . . . . . . . . . . . . 9 4.2. Matching the question section . . . . . . . . . . . . . . 9
4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 9 4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . 12
6. Accepting only in-domain records . . . . . . . . . . . . . . . 12 6. Accepting only in-domain records . . . . . . . . . . . . . . . 13
7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 13 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 14
7.1. Symbols used in calculation . . . . . . . . . . . . . . . 13 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 14
7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 15
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Repetitive spoofing attempts for a single domain name . . 16 8.1. Repetitive spoofing attempts for a single domain name . . 17
9. Forgery countermeasures . . . . . . . . . . . . . . . . . . . 17 9. Forgery countermeasures . . . . . . . . . . . . . . . . . . . 18
9.1. Query matching rules . . . . . . . . . . . . . . . . . . . 17 9.1. Query matching rules . . . . . . . . . . . . . . . . . . . 18
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 . . 18
9.2.1. Justification and Discussion . . . . . . . . . . . . . 18 9.2.1. Justification and Discussion . . . . . . . . . . . . . 19
9.3. Spoof detection and countermeasure . . . . . . . . . . . . 18 9.3. Spoof detection and countermeasure . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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 10, line 29 skipping to change at page 10, line 29
Less common resolving servers choose a random port per outgoing Less common resolving servers choose a random port per outgoing
query. If this strategy is followed, this port number can be query. If this strategy is followed, this port number can be
regarded as an additional ID field, again containing up to 16 bits. regarded as an additional ID field, again containing up to 16 bits.
If the maximum ports range is utilized, on average, around 32256 If the maximum ports range is utilized, on average, around 32256
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 query as ports below 1024 may be unavailable for use, of the original query as ports below 1024 may be unavailable for use,
leaving 64512 options. leaving 64512 options.
It is in general safe for DNS to use ports in the range 1024-49152
even though some of these ports are allocated to other protocols.
DNS resolvers will not be able to use any ports that are already in
use. If a DNS resolver uses a port it will release that port after a
short time and migrate to a different port. Only in the case of high
volume resolver is it possible that an application wanting a
particular UDP port suffers a long term block-out.
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.6. Have the response arrive before the authentic response 4.6. Have the response arrive before the authentic response
Once any packet has matched the previous four conditions (plus Once any packet has matched the previous four conditions (plus
possible additional conditions), no further responses are generally possible additional conditions), no further responses are generally
accepted. accepted.
skipping to change at page 17, line 46 skipping to change at page 18, line 46
o Use multiple different source ports simultaneously in case of o Use multiple different source ports simultaneously in case of
multiple outstanding queries; multiple outstanding queries;
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)
Resolvers that have multiple IP addresses SHOULD use them in an Resolvers that have multiple IP addresses SHOULD use them in an
unpredictable manner for outgoing queries. unpredictable manner for outgoing queries.
Resolver implementations SHOULD provide means to avoid usage of
certain ports.
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 ([RFC4301]) 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 (TSIG, SIG(0)), resolver implementations MAY waive above available (TSIG, SIG(0)), resolver implementations MAY waive above
rules, and rely on this guarantee instead. 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
(pseudo-)random generator, as described in [RFC4086]. (pseudo-)random generator, as described in [RFC4086].
9.2.1. Justification and Discussion 9.2.1. Justification and Discussion
Since an attacker can force a full DNS resolver to send queries to Since an attacker can force a full DNS resolver to send queries to
skipping to change at page 19, line 37 skipping to change at page 20, line 37
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.
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.
DNS recursive servers sitting behind at NAT or a statefull firewall
may consume all available NAT translation entries/ports when
operating under high query load. Port randomization will cause
translation entries to be consumed faster than with fixed query port
. To avoid this NAT boxes and statefull firewalls can/should purge
outgoing DNS query translation entries 10-17 seconds after the last
outgoing query on that mapping was sent. [RFC4787] compliant devices
need to treat UDP messages with port 53 differently than most other
UDP protocols.
To minimize the potential that port/state exhaustion attacks can be
staged from the outside, it is recommended that services which
generate number of DNS queries for each connection, should be rate
limited. This applies in particular to e-mail servers
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
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.
skipping to change at page 22, line 36 skipping to change at page 24, line 36
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000. (TSIG)", RFC 2845, May 2000.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013, Security Services and Procedures", BCP 46, RFC 3013,
November 2000. November 2000.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
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.
13.2. Informative References 13.2. Informative References
[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.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008. October 2008.
[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
skipping to change at page 25, line 4 skipping to change at line 840
Email: bert.hubert@netherlabs.nl Email: bert.hubert@netherlabs.nl
Remco van Mook Remco van Mook
Equinix Equinix
Auke Vleerstraat 1 Auke Vleerstraat 1
Enschede 7521 PE Enschede 7521 PE
The Netherlands The Netherlands
Email: remco@eu.equinix.com Email: remco@eu.equinix.com
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.
 End of changes. 13 change blocks. 
32 lines changed or deleted 71 lines changed or added

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