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

[神明達哉 <[e-mail]>]

At Wed, 3 Aug 2016 13:32:56 -0700,
Warren Kumari <[e-mail]> wrote:

> 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.

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