<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
Vernon Schryver wrote:
<blockquote cite="mid:201303311430.r2VEUBa2052531@calcite.rhyolite.com"
type="cite">
<blockquote type="cite"><pre wrap=""> [Maybe TCPCT could help.]
</pre></blockquote>
<pre wrap=""><!---->
I don't see anything in <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6013">https://tools.ietf.org/html/rfc6013</a> that reduces
the costs of TCP for DNS.</pre>
</blockquote>
<br>
there is no direct example showing this in RFC 6013, but it's there. let
me explain.<br>
<br>
in TCPCT, there's a cookie pair that can be (opportunistically -- this
isn't a requirement) saved after FIN and reused on the next connection.
if this cookie pair is presented to a responder who recognizes it
(because the responder also saves these in some kind of short term
cache) then the responder can re-use the old window size.<br>
<br>
also, in TCPCT there's room for a payload in the SYN.<br>
<br>
in practice this means a normal three way handshake for the first
connection between an endpoint-pair, but there's a single round trip on
any subsequent connection between that endpoint-pair, involving one
packet to send the request, and one or more packets to send the
response. <br>
<br>
there's zero cost to a responder for an embryonic tcp connection in
tcpct, everything needed between the initial syn and the syn-ack is
contained in a cookie pair that the client has to include in its next
packet. obviously there's some cost to remembering previous cookies but
it's optional and can be managed in the usual LRU way. this is why i was
happy to see this solved at the transport level rather than at the dns
level -- i think tcp/80 could benefit from zero state cost in
responders, and single round trip for request plus multipacket response,
too.<br>
<br>
see also:
<a class="moz-txt-link-rfc2396E" href="http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf"><http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf></a>.<br>
<br>
<blockquote cite="mid:201303311430.r2VEUBa2052531@calcite.rhyolite.com"
type="cite">
<pre wrap=""> Perhaps you mean T/TCP to bypass the TCP
3-way handshake.</pre>
</blockquote>
<br>
no. t/tcp wasn't secure in several important ways. we have to be able to
send a multi-packet response with no chance that we're sending it to
someone whose source address was spoofed.<br>
<br>
<blockquote cite="mid:201303311430.r2VEUBa2052531@calcite.rhyolite.com"
type="cite">
<pre wrap="">...
If you can change the software on 21 million open resolvers
to use DNS over T/TCP, why do the the easier thing of closing them?</pre>
</blockquote>
<br>
i agree that closing them is the right thing, but for a different
reason: there's no use-case for keeping them open in any form. so when i
argue for TCPCT i'm arguing for it on the general principle that we'd
like a responder to have proof of requester identity before sending a
multipacket response. we would not use these powers to make OR
ubiquitous.<br>
<br>
<br>
<blockquote cite="mid:201303311430.r2VEUBa2052531@calcite.rhyolite.com"
type="cite">
<pre wrap="">If you could change their software and want to keep them open, then
you could install RRL and DNS cookies. The problems that RRL has on
resolvers would be solved with DNS cookies. DNS cookies don't need
kernel changes but only changes in DNS client and server software.
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03">https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03</a></pre>
</blockquote>
<br>
alas, this feature combination is far more likely to see wide use than
TCPCT is.<span style="font-family: monospace;"><br>
<br>
paul<br>
</span>
<blockquote cite="mid:201303311430.r2VEUBa2052531@calcite.rhyolite.com"
type="cite">
</blockquote>
</body></html>