Subject: Re: [DNSOP] [dnssec-deployment] root DNSKEY response size research

From: Steve Crocker <[email-masked]>
Date: Sat, 5 Sep 2009 17:58:20 -0700

Folks,

Attached is a spread sheet fitting David Blacka's data to some  
formulas.  There is strong agreement except for three data points.  In  
private exchange with David, he agrees these are probably slight  
transcription errors and the formulas are probably right.

There are seven(!) independent variables in the formulas.  One of  
them, the length of the KSK has not been exercised, so the formulas  
probably need further adjustment.  In other words, when we see the  
effect of changing the length of the KSK, there will be some  
additional terms and the constant term will likely be adjusted sharply  
downward.

This is important work and vital for understanding the impact of path  
MTU and whether the priming sequence will be affected in a substantial  
way when the root is signed.  I applaud David for his contribution.

Steve

On Sep 4, 2009, at 2:54 PM, David Blacka wrote:

>
> As part of the effort to sign the root, we thought it might be a good
> idea to look at possible root DNSKEY responses sizes given different
> key sizes and key rollover scenarios.
>
> Tests were run with BIND 9.6.0-P1 and NSD 3.2.2.  BIND 9.6 gives back
> "minimal response" answers for DNSKEY, NSD 3.2.2 does not (although,
> it should be noted, NSD 3.2.3 does).
>
> For the full response case, note that the IPv4 glue is 16 bytes per
> record, and IPv6 glue is 28 bytes per record.  This works out to a
> total of 404 octets of glue records.  Thus, the full responses may
> be truncated up to 404 bytes without setting TC.
>
> In the results below:
>
>  a) "minimal response" is the size of the BIND 9.6 response (that is,
>  the DNSKEY response with only the answer section and the OPT RR.
>  b) "minimum no-tc response" is the size of the NSD 3.2.2 response,
>  minus the additional section, although including the OPT RR.  This
>  is the minimum sized response prior to setting the TC bit.
>  c) "full response" is the size of the NSD 3.2.2 response including
>  the additional section.
>
> Note that the size of the authority section is predictable given a ZSK
> size (it varies by the size of the root NS RRSIG), and the additional
> section size is a constant (404 octets).
>
> Three different sets of key sizes were tested.  Each set of tests with
> a given set of keys is a round, for three rounds of tests.  Within a
> round, 6 different cases were tested, encompassing different root
> DNSKEY rollover states.
>
> Round 1:
>
>  KSKs are 2048 bits, ZSKs are 1024 bits.
>
>  authority size: 369
>
> Case 1: one KSK, one ZSK.
>
>  minimal response       :  736
>  minimum no-tc response : 1105
>  full response          : 1509
>
> Case 2: one KSK, two ZSKs (ZSK roll)
>
>  minimal response       :  883
>  minimum no-tc response : 1252
>  full response          : 1656
>
> Case 3: two KSKs (and two KSK RRSIGs), one ZSK (KSK roll)
>
>  minimal response       : 1297
>  minimum no-tc response : 1666
>  full response          : 2070
>
> Case 4: two KSKs (and two KSK RRSIGs), two ZSKs (KSK and ZSK roll)
>
>  minimal response       : 1444
>  minimum no-tc response : 1813
>  full response          : 2217
>
> Case 5: two KSKs (and only one KSK RRSIG), one ZSK (KSK roll)
>
>  minimal response       : 1011
>  minimum no-tc response : 1380
>  full response          : 1784
>
> Case 6: two KSKs (and only one KSK RRSIG), two ZSKs (KSK and ZSK roll)
>
>  minimal response       : 1158
>  minimum no-tc response : 1527
>  full response          : 1931
>
> Round 2:
>
>  KSKs are 2048 bits, ZSKs are 1280 bits.
>
>  authority size: 401
>
> Case 1: one KSK, one ZSK
>
>  minimal response       :  768
>  minimum no-tc response : 1169
>  full response          : 1573
>
> Case 2: one KSK, two ZSKs (ZSK roll)
>
>  minimal response       :  947
>  minimum no-tc response : 1384
>  full response          : 1752
>
> Case 3: two KSKs (and two KSK RRSIGs), one ZSK (KSK roll)
>
>  minimal response       : 1329
>  minimum no-tc response : 1740
>  full response          : 2134
>
> Case 4: two KSKs (and two KSK RRSIGs), two ZSKs (KSK and ZSK roll)
>
>  minimal response       : 1508
>  minimum no-tc response : 1909
>  full response          : 2313
>
> Case 5: two KSKs (and only one KSK RRSIG), one ZSK (KSK roll)
>
>  minimal response       : 1043
>  minimum no-tc response : 1444
>  full response          : 1848
>
> Case 6: two KSKs (and only one KSK RRSIG), two ZSKs (KSK and ZSK roll)
>
>  minimal response       : 1222
>  minimum no-tc response : 1623
>  full response          : 2027
>
> Round 3:
>
>  KSKs are 2048 bits, ZSKs are 2048 bits.
>
>  authority size: 497
>
> Case 1: one KSK, one ZSK
>
>  minimal response       :  864
>  minimum no-tc response : 1361
>  full response          : 1765
>
> Case 2: one KSK, two ZSKs (ZSK roll).
>
>  minimal response       : 1139
>  minimum no-tc response : 1636
>  full response          : 2040
>
> Case 3: two KSKs (and two KSK RRSIGs), one ZSK (KSK roll)
>
>  minimal response       : 1425
>  minimum no-tc response : 1919
>  full response          : 2326
>
> Case 4: two KSKs (and two KSK RRSIGs), two ZSKs (KSK and ZSK roll)
>
>  minimal response       : 1700
>  minimum no-tc response : 2197
>  full response          : 2601
>
> Case 5: two KSKs (and only one KSK RRSIG), one ZSK (KSK roll)
>
>  minimal response       : 1139
>  minimum no-tc response : 1636
>  full response          : 2040
>
> Case 6: two KSKs (and only one KSK RRSIG), two ZSKs (KSK and ZSK roll)
>
>  minimal response       : 1414
>  minimum no-tc response : 1911
>  full response          : 2315
>
>
> --
> David Blacka                          <[email-masked]>
> Sr. Engineer          VeriSign Platform Product Development
>