warning, there are some mostly-off-topic comments here regarding dns cookies, tcp cookies, tcp fast open, and the TCP/TLS proposal from ISI. but first:
> Tony Finch <mailto:d...@dotat.at> > Tuesday, December 02, 2014 1:52 AM > > Why is back-to-back fragmented UDP OK when back-to-back unfragmented > UDP isn't? "OK" is a loaded term in this context. there exist "blast" protocols using UDP that deliberately flood the channel and then ask for retransmissions on the buffer overruns, and for local area networks this is often the fastest (by clock time) way to transfer a large amount of data. so, back-to-back unfragmented UDP is not nec'y "NOT OK". because fragments are sent back to back, higher level protocols that know they're sending datagrams large enough that they'll have to be fragmented, are advised to not send these large datagrams back to back, at least in the WAN case (as is most common for DNS). the idea is that switch port buffering can tolerate an occasional microburst, and likewise router port buffering, but a smart switch or router design will keep those port buffers short to avoid what jim gettys, dave taht, and others have been calling <http://bufferbloat.net/>. so, microbursts on the level of a single datagram that requires fragmentation are expected and well handled, whereas longer, um, "minibursts" are not expected and can cause trouble, either because your data path has just the right amount of buffering, or because it has too much. (different kinds of trouble, but trouble either way.) > > Why is TCP such a problem for name servers when web servers seem to > cope OK? commercial web servers handle large numbers of simultaneous TCP sessions because they're built that way. but if you take an average business's web site built on top of linux or apple or freebsd or windows, you'll find that the out-of-the-box file descriptor quota (and TCB quota in the kernel, which is closely related but not the same quota) is attackable. same thing for SYN floods, or my favourite for attacking TCP/53, the slow loris attack where i actually am sending packets once in a while and properly processing the ACKs but it takes quite a while to get a full question asked. so, no kernel timeouts occur, and in DNS, short of the dickenson TCP proposal, the server-side timeouts are large. nobody's saying that a dns protocol could not be specified with workable timeout handling, or that a dns server couldn't be built that would withstand most non-state-actor and/or commercial attacks. however, that's not the environment we're in today. far from it. --- as a side note, i pushed moderately hard for RFC 6013 adoption, but got shot down. if you found that RFC difficult to process because it's extremely concept-dense and very precisely drawn, try the older Usenix ;login: article written by metzger, simpson, and vixie: http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf (no paywall) my grand contribution to this scheme was that cookies were no longer modal as in the bernstein tcp cookie design; there was _never_ state on the server side until a client had echoed back the server's initial timestamp. this had two very interesting effects: 1. FIN was advisory. the compressed state on the server side could be opportunistically kept around, so that on a subsequent SYN, the old window size would still be known. 2. SYN flooding was impossible. there was no server side state, so, no state quota. simpson also put in the most interesting thing we all loved from t/tcp, which was a SYN payload of up to 64 octets. this meant most DNS queries could be transmitted with the SYN, and many servers would be able to send a multipacket response to this query. additionally, somebody had the idea of putting SYN and FIN in the same segment, which meant that once steady state had been reached, there was one round trip, single packet out, one or more packets back, and then back to compressed-opportunistic-state. it was a way to do what heidemann and manning are currently proposing, but without the RAM requirements. it was a way to do what tcp-fastopen is attempting, but, securely. it was a way to do what current tcp-cookies does, but non-modally, all the time, every time. i expected a better reception for it here than i got. (especially given the possibilities for other TCP protocols, such as HTTP.) it's definitely worth reading that Usenix ;login: article (see reference above), and also RFC 6013 if you've got the fortitude for it. i'd be extremely grateful to discuss this technology with... anybody? now it looks like ISC and Eastlake are back to working together on dns cookies, so that's the likely direction. -- Paul Vixie
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
