Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers

From: Alex Bligh <[email-masked]>
Date: Tue, 21 Feb 2006 19:11:14 +0000

--On 21 February 2006 18:26 +0000 Geoffrey Sisson <[email-masked]> 
wrote:

> A potential DoS condition exists in which the operator of a malicious
> server could select an impractically high number of iterations for the
> NSEC3 RRs in an signed zone.  The NSEC3 RDATA format permits values as
> high as 2 ^ 23, or 8,388,608 (N.B. this is a change in -04; in -03 it
> was 2 ^ 24).  Consequently, when a resolver receives multiple queries
> for names (existent or non-existent) in this zone, the resolver must
> perform the same number of hash iterations for each query.  This could
> result in a significant denial-of-service on the resolver.

Hmmm... Off the wall idea for today: Suppose that rather than using
just some local resolver config knob, you looked at the parent
zones number of hash iterations, and did not allow a number of
hash iterations which exceeded both some function of that AND the
config knob.

Then, when as and when the root goes NSEC3, increasing computation
power could be reflected in an increase in the root hash iterations,
TLD iterations, etc. etc.

You'd still have your local config knob for delegations which
went (say) NSEC3->NSEC->NSEC3.

Alex

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Feb 2006 14:39:34 -0800

>>>>> On Tue, 21 Feb 2006 18:26:36 GMT, Geoffrey Sisson <[email-masked]> said:

Geoffrey> 1.  Should an upper limit be specified in the standard?

Geoffrey> 2.  If so, should the upper limit be specified in a separate document
Geoffrey> so that the it may be updated without having to re-publish
Geoffrey> the entire standard.

It would make sense (to me) not to specify a particular number as
though-shall, but rather as a "at the time of this writing a decent
default to choose"...  Ideally, resolvers should be configurable with
this upper limit and it should be changeable.

Specifying a maximum will help interoperability (zone operators that
pick a higher iteration factor than the default deployed max will run
into issues).  However, it also locks you into a time frame where the
number either has too be too small for the future (deployment in the
future with faster processors may want more iterations) or too large
for the present (trying to pick a large enough number for the future
will invariably mean that you'll still allow for more of the DoS
attack today that you're trying to prevent).

-- 
Wes Hardaker
Sparta, Inc.