AW: [6bone] big packets - redux

[Bill Manning]

 key length (in bits) generates KEY/SIG rrs that are in bytes.

for example:

$dig . ns                 
...
;; WHEN: Tue Oct  8 10:17:24 2002
;; MSG SIZE  rcvd: 196

while:

$dig . ns +dnssec
...
;; WHEN: Tue Oct  8 10:18:51 2002
;; MSG SIZE  rcvd: 1822

	the change in bytes is nearly an order of magnitude
	and the key length was 512 bits.

this triggers UDP fragmentation.



% To me there seems to be a confusion of units in this 
% posting.
% Encryption keys are typically measured in bits,
% whereas MTU size is in bytes.
% 
% It should therefore be possible to send all, but
% the largest keys unfragmented in one paket.
% 
% Regards,
% Thomas
%  
% 
% > -----Ursprungliche Nachricht-----
% > Von: Bill Manning [mailto:bmanning@ISI.EDU]
% > Gesendet: Samstag, 5. Oktober 2002 01:44
% > An: 6bone@ISI.EDU
% > Betreff: [6bone] big packets - redux
% > 
% > 
% >  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
% > _______________________________________________
% > 6bone mailing list
% > 6bone@mailman.isi.edu
% > http://mailman.isi.edu/mailman/listinfo/6bone
% > 
% 


-- 
--bill