[e2e] 64-bit timestamps?

[David P. Reed]

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.

---------------
from appendix B of RFC 1323:
----------------


      B.2 Closing and Reopening a Connection

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:

   1. Implement the full-duplex reliable close handshake of TCP.

      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.)

      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.

      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.

   2. Allow old duplicate segments to expire.

      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.

      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.

      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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090908/03944ac4/attachment.html