Subject: Publication request for draft-ietf-dnsext-forgery-resilience-07.txt

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 25 Aug 2008 14:54:50 -0400

Mark,

This is a request to publish the document as Standards Track document,

Title           : Measures for making DNS more resilient against forged answers
Author(s)       : A. Hubert, R. van Mook
Filename        : draft-ietf-dnsext-forgery-resilience-07.txt
Date            : August 25 2008
Document shepherd: Olafur Gudmundsson [email-masked]

1) Have the chairs personally reviewed this version of the ID and do
     they believe this ID is sufficiently baked to forward to the IESG
     for publication?

There is one nit according to idnits 2.08.10 (via tools.ietf.org).
The nit is that Informational RFC 3833 is a normative reference.
RFC 3833 is about the DNS threat model, this document addresses one of the
treats identified in RFC 3833 and describes techniques to make it harder
to exploit that particular threat.
We are not sure the reference should be moved between sections or not.

2) Has the document had adequate review from both key WG members and
     key non-WG members? Do you have any concerns about the depth or
     breadth of the reviews that have been performed?

Yes during last-call this document has been reviewed in depth by
a large number of working group members.
This particular document and the recent DNS exploits that attempt to
poison DNS caches, have brought number of new people to the working group.
We have no issue with the extent of reviews.

There is strong consensus to advance the document.

3) Do you have concerns that the document needs more review from a
     particular (broader) perspective (e.g., security, operational
     complexity, someone familiar with AAA, etc.)?

We think this document has had sufficient review.

4) Do you have any specific concerns/issues with this document that
     you believe the ADs and/or IESG should be aware of? For example,
     perhaps you are uncomfortable with certain parts of the document,
     or whether there really is a need for it, etc., but at the same
     time these issues have been discussed in the WG and the WG has
     indicated it wishes to advance the document anyway.

The only issues that people brought up are:
         Standards track vs. BCP.
         The TCP fallback

On the first one most people stated preference to one or the other but at
the same time said they could live with the other.
The requirement in section 9 that resolvers be capable of using
multiple source ports at once is arguably a new requirement, and could
have inter operation effects.
See:
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00873.html

As for the TCP fallback there is some concern in the operating community
that extensive use of TCP by resolver may cause problems. The chairs and
editors point out that TCP is an allowed transport protocol thus recommending
its use in certain situations, in particular when under attack is justified.

5) How solid is the WG consensus behind this document?  Does it
     represent the strong concurrence of a few individuals, with others
     being silent, or does the WG as a whole understand and agree with
     it?

The consensus is strong, on the document as whole.

6) Has anyone threatened an appeal or otherwise indicated extreme
     discontent?  If so, please summarize what are they upset about.

No one has threatened an appeal.

7) Have the chairs verified that the document adheres to _all_ of the
     ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes but see note #1 above.

8) For Standards Track and BCP documents, the IESG approval
     announcement includes a write up section with the following
     sections:

     - Technical Summary

     DNS uses UDP for most of its query resolution process, to protect against
     forged UDP replies DNS has relied on a Query-ID field that is 16 
bits long.
     The size of this field was adequate when network connections 
were slower than
     is common today. The document documents measures to extend the effective
     Query-ID by using all available UDP ports, different source address (when
     possible) and using different authorative servers.

     All of the measures documented in the document, have been in use 
in certain
     implementations for a long time, and recently been almost universally
     deployed in all major implementations.

     - Working Group Summary

     There is a broad consensus that this important document be published.

     - Protocol Quality

     The techniques described in the document have been implemented 
and are in use
     use by number of implementations, with no interoperabilty 
issues. The only issues
     observed have been related to inability to allocate large number 
of open ports on
     certain operating systems, and firewalls/IDS not expecting the use of
     random ports by DNS resolvers.

       Olafur & Andrew

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>