draft-ietf-dnsext-forgery-resilience-00.txt   draft-ietf-dnsext-forgery-resilience-01.txt 
DNS Extensions (DNSEXT) A. Hubert DNS Extensions (DNSEXT) A. Hubert
Internet-Draft Netherlabs Computer Consulting BV. Internet-Draft Netherlabs Computer Consulting BV.
Updates: 1035 R. van Mook Updates: 1035 (if approved) R. van Mook
Intended status: Standards Track Virtu Intended status: Standards Track Virtu
Expires: July 15, 2007 January 11, 2007
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-00.txt draft-ietf-dnsext-forgery-resilience-01.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 33
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 July 15, 2007. This Internet-Draft will expire on January 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
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 make 'spoofing' a more fully, measures can already be taken to make 'spoofing' a
recursing nameserver many orders of magnitude harder. 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 answers quickly, as this potentially saves large to discard bogus answers quickly, as this potentially saves large
skipping to change at page 3, line 25 skipping to change at page 3, line 25
Question: a question sent out by a resolver, typically in a UDP Question: a question sent out by a resolver, typically in a UDP
packet packet
Answer: the answer sent back by an authoritative nameserver, Answer: the answer sent back by an authoritative nameserver,
typically in a UDP packet typically in a UDP packet
Third party: any host other than the resolver or the intended Third party: any host other than the resolver or the intended
recipient of a question. The third party may have access to a recipient of a question. The third party may have access to a
random authoritative nameserver, but has no access to packets random authoritative nameserver, but has no access to packets
transmitted by the Resolver ot 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
getting a chosen answer accepted getting a chosen answer accepted
Authentic answer: the answer that would be accepted if no third Authentic answer: the answer that would be accepted if no third
party interferes party interferes
Target domain: domain for which the attacker wishes to spoof in an Target domain: domain for which the attacker wishes to spoof in an
skipping to change at page 12, line 43 skipping to change at page 12, line 43
been queried a number of times within this hour, and given the short been queried a number of times within this hour, and given the short
TTL, this would lead to questions to authoritative nameservers, TTL, this would lead to questions to authoritative nameservers,
opening windows of opportunity. opening windows of opportunity.
7.1. Symbols used in calculation 7.1. Symbols used in calculation
Assume the following symbols are used: Assume the following symbols are used:
I: Number distinct IDs available (maximum 65536) I: Number distinct IDs available (maximum 65536)
P: Number of ports used (maximum around 64000, but often 1) P: Number of ports used (maximum around 64000 as ports under 1024
are not always available, but often 1)
N: Number of authoritative nameservers for a domain (averages N: Number of authoritative nameservers for a domain (averages
around 2.5) around 2.5)
F: Number of 'fake' packets sent by the attacker F: Number of 'fake' packets sent by the attacker
R: Number of packets sent per second by the attacker R: Number of packets sent per second by the attacker
W: Window of opportunity, in seconds. Bounded by the response W: Window of opportunity, in seconds. Bounded by the response
time of the authoritative servers (often 0.1s) time of the authoritative servers (often 0.1s)
skipping to change at page 16, line 11 skipping to change at page 16, line 11
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. Countermeasures 9. Countermeasures
NOTE: This section is expected to change, and is very much open to NOTE: This section is expected to change, and is very much open to
discussion! discussion!
Implementations MUST be able to send queries from ANY UDP port Implementations MUST be able to send queries from ANY UDP port
available to it.
Implementations SHOULD use good random source to select Query ID for Implementations SHOULD use good random source to select a Query ID
next query for next query
Implementations SHOULD NOT use UDP source ports <1024 for sending
queries
Implementations MUST use an as large as possible pool of UDP source
ports for sending queries
Implementations SHOULD be configurable to use one or multiple ports Implementations SHOULD be configurable to use one or multiple ports
for queries. for queries.
Implementations MAY be configurable to use one or more addresses for Implementations MAY be configurable to use one or more addresses for
queries queries
Implementations MUST suppress multiple identical queries to the SAME Implementations MUST suppress multiple simultaneous identical queries
server. to the SAME server.
Implementations MUST match answers to the following Implementations MUST match answers to the following
o Remote address o Remote address
o Local address o Local address
o Query port o Query port
o Query ID o Query ID
skipping to change at page 16, line 47 skipping to change at page 17, line 5
The document can not require the use of either multiple ports or The document can not require the use of either multiple ports or
addresses as that is an operational issue and should be addressed in addresses as that is an operational issue and should be addressed in
a separate document in DNSOP. a separate document in DNSOP.
NOTE! A previous version of requirements is listed below as an NOTE! A previous version of requirements is listed below as an
inspiration to further discussions: inspiration to further discussions:
Given the above, a resolver MAY/SHOULD/MUST: Given the above, a resolver MAY/SHOULD/MUST:
o Use an unpredictable source port from its available range for each o Use an unpredictable source port for outgoing queries from a range
outgoing query (53, or > 1024) of ports that is as large as possible
o Make use of all 16 bits of the ID field
o Make full use of all 16 bits of the ID field
o Assure that its choices of port and ID cannot be predicted by an o Assure that its choices of port and ID cannot be predicted by an
attacker having knowledge of its (pseudo-)random generator attacker having knowledge of its (pseudo-)random generator
o Not send out multiple equivalent questions outstanding to any o Not have multiple equivalent questions outstanding to any
authoritative server, unless all with identical ID and source port authoritative server, unless all with identical ID and source port
A resolver SHOULD offer diagnostics that enable the operator to A resolver SHOULD offer diagnostics that enable the operator to
determine a spoofing attempt is under way. determine a spoofing attempt is under way.
Operators SHOULD attempt to restrict recursing service, either full Operators SHOULD attempt to restrict recursing service, either full
or partial, to authorised users. or partial, to authorised users.
A resolver MAY use heuristics to detect an excess of unacceptable A resolver MAY use heuristics to detect an excess of unacceptable
answers and take measures if it believes an attempt is made to spoof answers and take measures if it believes an attempt is made to spoof
skipping to change at page 22, line 7 skipping to change at page 22, line 7
Remco van Mook Remco van Mook
Virtu Virtu
Auke Vleerstraat 1 Auke Vleerstraat 1
Enschede 7521 PE Enschede 7521 PE
The Netherlands The Netherlands
Email: remco@virtu.nl Email: remco@virtu.nl
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 15 change blocks. 
21 lines changed or deleted 28 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/