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

[Warren Kumari <[e-mail]>]

Apologies for the delay in responding.

On Wed, Aug 17, 2016 at 2:18 PM, 神明達哉 <[e-mail]> wrote:
> 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.

Thank you for your comments; we are trying to make it better, and
appreciate your review.

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

Thank you. Based on your previous comments I had tried to tone down /
scrub much of the DoS wording - I'd thought I'd achieved a reasonable
compromise, but I'll give it another whirl.
I like your above suggestion, and have added Section 6 - Benefits.
I have tried to explain the mitigation which this provides *under
ideal circumstances*. It decreases the number of queries sent by each
recursive being used as a reflector in the attack from close to
infinite (conservatively [a-z0-9\-]^label_length, or 37^63 (assuming
one label)) to something around 2*[entries_in_zone] (one for each
actual entry, one for each "hole").
I'm not sure that my explanation is a: useful or b: clear or c: correct :-)

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

Thank you. I have removed the "full-service" terminology, and replaced
it with "validating resolver" where applicable. In many cases the
"validating" bit was clear from context / was redundant and so I just
said "resolver" or "implementation" to improve readability. I also
added something to the terminology section basically explaining this.

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

How is:
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 certain DoS
attacks in some circumstances.

(I took your suggestion and made it even less strong)


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

Thanks, done.

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

Oh, yeah. Nice catch, done!

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

Oh, ta, thanks. I integrated previous comments in a bit of a rush.

W

> --
> JINMEI, Tatuya
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> 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