[6bone] big packets - redux

[Bill Manning]

 once more, with big packets....
 the topic was discussed on the keydist list.  Feedback is appreciated.
--------
        experimenting with DS keys of various lengths shows that 
        when keys are over a certain size, UDP fragmentation sets
        in.  In some cases, it is possible to actually get rollover
        to TCP (although this seems to be a corner case)

        now I've been told that UDP fragmentation can be a bad thing,
        leading to all sorts (well some kinds anyway) of odd 
        operational failures that are hard to debug.  UDP failure
        and rolling over to TCP is also considered a bad thing.

        so this question, "should key lengths be selected to 
        avoid fragmentation/TCP use?"

        if so, why?
        if not, why not?

        testing was done using single keys.  RSA/SHA1 keys of 512 & 1024
        bits, which generated "reasonable" packets.  RSA/SHA1 keys of 4096 
        bits, generated UDP fragmentation. Multiple keys will aggrevate the
        issue.

        Somewhat sidenote:  there has been some discussion that RSA keys 
        over 2048 in length incurred a significant performance impact over 
        smaller keys.  This performance impact hits the resolver though, 
        "on the wire" usage wasn't mentioned.  Further testing is needed.


Thoughtful responses follow:

-  "no" I don't think operational issues should dictate key
   lengths, but huge keys don't necessarily mean more secure either :)

-  some IDS/firewalls toss UDP packets larger than 512 bytes. Maybe the 
   right answer is to tune the EDNS packet size to avoid UDP 
   fragmentation?  4096 is bigger than most MTUs, but 1280 probably isn't, 
   and should be enough for most common responses.

- this is not just a server/resolver issue. if transit infrastructure is
  making assumptions on "viable" datagram sizes, we will have to make a 
  tradeoff in recommended key lengths.
  In an ideal world, security reasons (whatever that means) may be the only 
  vector for selecting length.  This being the "real" world, it may be that 
  to be useful, one has to trade of between "enough" crypto-strength and the 
  ability to deliver the key(s) to the intended target.)

- one experience is that keeping DNSSEC messages (plus overhead) below a
  MTU of 1500 can be sort of difficult and too restrictive besides.

- a general opinion is that the firewall or router that drops UDP fragments 
  or large UDP packets is broken and will need to be upgraded/replaced.
  if clients behind such broken devices set their EDNS0 max buffer size to 
  something that will fit in the MTU, everything should work.  There will
  probably be a lot of TCP DNS traffic, but it should work.

Acknowledgements:

        David Blacka  Scott Rose  Brian Wellington 
        Mark Andrews  Ed Lewis  Joahn Ihren  Olaf M. Kolkman

--bill