Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-01.txt

From: [email-masked]
Date: Wed, 03 Aug 2016 12:17:56 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Aggressive use of NSEC/NSEC3
        Authors         : Kazunori Fujiwara
                          Akira Kato
                          Warren Kumari
	Filename        : draft-ietf-dnsop-nsec-aggressiveuse-01.txt
	Pages           : 12
	Date            : 2016-08-03

Abstract:
   The DNS relies upon caching to scale; however, the cache lookup
   generally requires an exact match.  This document specifies the use
   of NSEC/NSEC3 resource records to generate negative answers within a
   range.  This increases resilience to DoS attacks, increases
   performance / decreases latency, decreases resource utilization on
   both authoritative and recursive servers, and also increases privacy.

   This document updates RFC4035 by allowing resolvers to generate
   negative answers based upon NSEC/NSEC3 records.

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.This document is being
   collaborated on in Github at: https://github.com/wkumari/draft-ietf-
   dnsop-nsec-aggressiveuse.  The most recent version of the document,
   open issues, etc should all be available here.  The authors
   (gratefully) accept pull requests.

   Known / open issues [To be moved to Github issue tracker]:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Aug 2016 13:32:56 -0700

We have updated this document with comments and feedback from Berlin.
We have also gone through and done another editing pass, removing a
significant amount of text which was intended to drive the discussion,
but would not really be useful in a published RFC.

Please review it, we believe that the document is ready (or almost
ready) for WGLC.

W

On Wed, Aug 3, 2016 at 12:17 PM,  <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Bob Harold <[email-masked]>
Date: Mon, 15 Aug 2016 12:20:02 -0400

> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-01

 Minor nit:
"Bob Harold" is listed twice in "10.  Acknowledgments".
I probably did not add enough value to be mentioned once, certainly not
twice.

-- 
Bob Harold

---

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Aug 2016 11:36:40 -0500

> I probably did not add enough value to be mentioned once, certainly not

Oh, thanks, good catch.
I've updated the version in Github: draft-ietf-dnsop-nsec-aggressiveuse

W

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Aug 2016 11:18:21 -0700

At Wed, 3 Aug 2016 13:32:56 -0700,

> Please review it, we believe that the document is ready (or almost

I see draft-ietf-dnsop-nsec-aggressiveuse-01 has been improved a lot.

Some comments on this version:

- general: there still seem to be a (IMO) misleading claim as if this
  technique were a strong mitigation against DoS attacks rather than a
  possible performance optimization.  I'll point out some specific
  cases below, but independently from whether/how to address these
  points, we might want to follow the style of
  draft-ietf-dnsop-nxdomain-cut-04.  It has a dedicated section (sec
  4) that discusses the benefit, and mentions its attack mitigation
  effect as a secondary benefit.  I think the same logic applies to
  nsec-aggressiveuse.

- general: I suggest removing/rephrasing the phrase "full-service
  resolver".  As far as I understand it, nsec-aggressiveuse is totally
  irrelevant to whether the resolver is "full-service" (which I
  interpret as performing recursive resolution from the root) or not.
  The only critical point for it to work is that the resolver has/uses
  cache and it performs DNSSEC validation.  As long as a resolver
  meets this condition, nsec-aggressiveuse should be equally
  usable/effective even if it only uses an external forwarder.  Since
  the use of cache is probably too obvious, a better terminology would
  be "validating resolver".

- general: I wonder whether we also want to use NSEC/NSEC3 for
  NOERROR-NODATA type of negative cache information.

- Abstract

   This increases resilience to DoS attacks, increases
   performance / decreases latency, decreases resource utilization on
   both authoritative and recursive servers, and also increases privacy.

  I suggest rephrasing it to be less misleading, e.g.,

   This increases performance / decreases latency, decreases resource
   utilization on both authoritative and recursive servers, and also
   increases privacy.  [It may also help increase resilience to DoS
   attacks to some extent.]

  The second sentence could simply be removed, but I added it in case
  if we really want to say something about it in the abstract.

- Section 1

   [...]  This method of negative caching requires
   exact matching; this leads to unnecessary additional lookups, which
   have negative implications for DoS survivability, increases latency,
   leads to extra resource utilization on both authoritative and
   recursive servers, and decreases privacy by leaking queries.

  I suggest removing "which have negative implications for DoS
  survivability" to be less misleading.

- Section 5.2

   [...] It SHOULD provide a configuration switch to
   disable aggressive use of NSEC and allow it to be enabled or disabled
   for specific zones.

  I suggest s/specific zones/specific domains/ since it's not trivial
  for a recursive server operator to know whether a particular domain
  name is a zone apex or not at the time of configuring the server.

- Section 5.4

   and it may be justified for performance and other benefits.  (Note
   that, so far, this is orthogonal to "when aggressive use (of NSEC) is
   enabled").

   Furthermore, when aggressive use of NSEC is enabled, the aggressive
   use of cached deduced wildcard will be more effective.

  This text seems to be derived from a prior review comment of mine,
  which was a bit too casual.  I suggest revising this part as
  follows:

   and it may be justified for performance and other benefits.

   Such aggressive use of cached deduced wildcard can be employed
   independently from aggressive use of NSEC.  But, it will be more
   effective when both are enabled since the resolver can determine
   the name subject to wildcard would not otherwise exist more
   efficiently.

--
JINMEI, Tatuya