<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">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:<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:alpine.LSU.2.00.1412020949040.27029@hermes-1.csi.cam.ac.uk"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="dot@dotat.at" photoname="Tony Finch"
src="cid:part1.03050107.02000108@redbarn.org"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:dot@dotat.at"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Tony Finch</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Tuesday, December
02, 2014 1:52 AM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><div><!----><br>Why
is back-to-back fragmented UDP OK when back-to-back unfragmented UDP
isn't?<br></div></div>
</blockquote>
<br>
"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".<br>
<br>
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 <a class="moz-txt-link-rfc2396E" href="http://bufferbloat.net/"><http://bufferbloat.net/></a>.<br>
<br>
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.)<br>
<blockquote style="border: 0px none;"
cite="mid:alpine.LSU.2.00.1412020949040.27029@hermes-1.csi.cam.ac.uk"
type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<div><br>Why is TCP such a problem for name servers when web servers
seem to cope OK?<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
---<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf">http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf</a>
(no paywall)<br>
<br>
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:<br>
<br>
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.<br>
<br>
2. SYN flooding was impossible. there was no server side state, so, no
state quota.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
now it looks like ISC and Eastlake are back to working together on dns
cookies, so that's the likely direction.<br>
<br>
<div class="moz-signature">-- <br>Paul Vixie<br>
</div>
</body></html>