<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
In regard to DNS security issues, I suggest reading Appendix B of RFC
1323 on whether PAWS helps. (I quote B.2 below). Since DNS queries do
not *require* the full duplex TCP close to be reliable (the close
provides no correctness to the DNS app), only the second point in B.2
really ought to matter. But PAWS may not be useful, since DNS itself
might be made to maintain state across connections, moving the problem
out of TCP and into the app (DNS) layer where it probably belongs.<br>
<br>
---------------<br>
from appendix B of RFC 1323:<br>
----------------<br>
<h3>B.2 Closing and Reopening a Connection</h3>
<p></p>
<p> When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT
state ties up the socket pair for 4 minutes (see Section 3.5 of
[Postel81]. Applications built upon TCP that close one connection and
open a new one (e.g., an FTP data transfer connection using Stream
mode) must choose a new socket pair each time. The TIME- WAIT delay
serves two different purposes:<br>
<br>
</p>
<p></p>
<ol>
<li> Implement the full-duplex reliable close handshake of TCP.
<p> The proper time to delay the final close step is not really
related to the MSL; it depends instead upon the RTO for the FIN
segments and therefore upon the RTT of the path. (It could be argued
that the side that is sending a FIN knows what degree of reliability it
needs, and therefore it should be able to determine the length of the
TIME-WAIT delay for the FIN's recipient. This could be accomplished
with an appropriate TCP option in FIN segments.)
</p>
<p> Although there is no formal upper-bound on RTT, common network
engineering practice makes an RTT greater than 1 minute very unlikely.
Thus, the 4 minute delay in TIME-WAIT state works satisfactorily to
provide a reliable full-duplex TCP close. Note again that this is
independent of MSL enforcement and network speed.
</p>
<p> The TIME-WAIT state could cause an indirect performance problem
if an application needed to repeatedly close one connection and open
another at a very high frequency, since the number of available TCP
ports on a host is less than 2**16. However, high network speeds are
not the major contributor to this problem; the RTT is the limiting
factor in how quickly connections can be opened and closed. Therefore,
this problem will be no worse at high transfer speeds.
</p>
<p> </p>
</li>
<li> Allow old duplicate segments to expire.
<p> To replace this function of TIME-WAIT state, a mechanism would
have to operate across connections. PAWS is defined strictly within a
single connection; the last timestamp is TS.Recent is kept in the
connection control block, and discarded when a connection is closed.
</p>
<p> An additional mechanism could be added to the TCP, a per-host
cache of the last timestamp received from any connection. This value
could then be used in the PAWS mechanism to reject old duplicate
segments from earlier incarnations of the connection, if the timestamp
clock can be guaranteed to have ticked at least once since the old
connection was open. This would require that the TIME-WAIT delay plus
the RTT together must be at least one tick of the sender's timestamp
clock. Such an extension is not part of the proposal of this RFC.
</p>
<p> Note that this is a variant on the mechanism proposed by
Garlick, Rom, and Postel [Garlick77], which required each host to
maintain connection records containing the highest sequence numbers on
every connection. Using timestamps instead, it is only necessary to
keep one quantity per remote host, regardless of the number of
simultaneous connections to that host.
</p>
</li>
</ol>
<br>
</body>
</html>