Subject: Re: More on NSEC2 label size and DoS

From: [email-masked]
Date: Wed, 26 May 2004 10:20:37 +0200 (CEST)

btw, if hashes are per owner name instead of per label, then other size
issues are at hand, since for every intermediate label level (empty non
terminal) a new NSEC+SIG (or EXIST) needs to be created.

That hurts in zones under ip6.arpa and e164.arpa.

Roy

On Wed, 26 May 2004 [email-masked] wrote:

> Hi,
>
> I still see a technical limit with NSEC2:
>
> 1) multiple hashed labels.
>
> I assume that every label needs to be hashed individually (Ben ?). Due to
> the SHA-1 digest size in base32, (32 characters), plus 1 byte label
> length+type, and a maximum owner name length of 255 bytes, there is a
> maximum of 7 hashed labels, i.e., there are issues for names like:
>
> 1.1.1.1.1.2.2.2.2.3.3.1.2.3.4.in-addr.arpa. and
> 5.4.1.4.1.1.0.1.6.3.1.e164.arpa.
>
> 2) DoS issue with multiple labels.
>
> Since a hash(label) needs to be performed by the server to look up
> (internally) the proper NSEC for proof, the effort for creating a response
> would be higher then the effort for sending a query, compared to NSEC or
> non-DNS.
>
> Roy
>
> --
> 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/>
>

--
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: Jim Reid <[email-masked]>
Date: Wed, 26 May 2004 11:13:38 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> btw, if hashes are per owner name instead of per label, then
    roy> other size issues are at hand, since for every intermediate
    roy> label level (empty non terminal) a new NSEC+SIG (or EXIST)
    roy> needs to be created.

    roy> That hurts in zones under ip6.arpa and e164.arpa.

Something similar to NSEC2 would be pointless for e164.arpa because
the name space is regular and well-known: eg all North American E.164
numbers are exactly 10 digits long after the +1. Enumeration of this
name space using DNS lookups is a no-brainer irrespective of how or if
the zones get signed.

---

From: [email-masked]
Date: Wed, 26 May 2004 18:59:39 +0200 (CEST)

On Wed, 26 May 2004, Ben Laurie wrote:

> [email-masked] wrote:
> This is true. I have not calculated how much it hurts. It is related to
> the sparseness of the domains. Are there figures for those?
>
> A back of the envelope calculation I did on the plane says that for e164
> in dense domains, the hit is 10-100% extra. For sparse domains it can be
> much higher, but presumably sparse domains are small.

Okay, the problem is not e164 but ip6.arpa:

9.1.1.0.6.0.1.0.7.8.0.0.2.9.1.0.a.0.0.8.1.0.0.0.0.1.6.0.1.0.0.2.ip6.arpa.

Remember, at _each_ intermediate label level including empty non-terminals
(in the above example there are 35 labels) a NSEC (or EXIST) is needed for
every occuring value at that label.

Roy