Re: [Tsvwg] TCP Question: Reuse of TCB's in time-wait state:

["sanjay kaniyar" <[e-mail]>]

1. A connection which used time-stamps can't be re-instated if the 
time-stamps are not guaranteed to be monotonically increasing across 
incarnations of a connection. I have not come across an implementation which 
does it that way though. (Would sombody do it if they want to use timestamps 
with different granularities for diffent data rate?)

2. Here is how the reuse works today (for passive open):

- When a connection goes to time-wait, along with the invariants of the 
connection, the rcv_next and snd_next are stored. A timer is started for 2 
MSL.

- When a SYN arrives with ISN = i, if "i > rcv_next", the TCB is moved back 
to SYN-RCVD and ISN = snd_next + 128K is sent back.

- There are 3 (remote) ways in which this can actually break. (a) The client 
sending the active SYN should generate ISNs which wrap around within 2 MSL. 
RFC793 etc suggests a wrap around time of 4.55 hours, so this should not be 
a problem as long it is followed reasonably. (b) If the same connection is 
reused at a rate of 2^32/(128K*2*MSL) (or smaller than this, with fast data 
transfer). This can easily be protected with a counter, if it is perceived 
to be an issue but I very much doubt it would be in practice. (c) A 
connection proceeds at a rate with transfer rate in Bytes > (2^32/2*MSL), in 
which case time-stamps should be used. This can be used to not reuse the 
tw-tcb, if the issue referenced in (1) is found to be commonplace.

- Note that this clearly protects against old duplicates in both directions. 
The appendix of RFC1185 does not seem to take the sequence number check (i > 
rcv_next) into account when it analyzes the failure cases.

If you can you think of a scenario which actually breaks because of this, 
please illustrate it with an example (assuming quiet-time is followed after 
boot).

3. This contention aside, my interest in this topic is to get opinions about 
what could possibly break (that is not already compromised by the 
tw-reuse-for-passive-open, if any) by tw-reuse-for-active-open. Your 
thoughts on that are welcome.

Thanks,
Sanjay


>From: Joe Touch <[e-mail]>
>To: sanjay kaniyar <[e-mail]>
>CC: [e-mail], [e-mail]
>Subject: Re: [Tsvwg] TCP Question: Reuse of TCB's in time-wait state:
>Date: Wed, 24 Oct 2001 10:53:29 -0700
>
>
>
>sanjay kaniyar wrote:
>
>>1. I went through the paper you pointed out, it does not seem to address
>>the question I have. It basically describes alternatives of how to move
>>a TW-TCB from the server to the client, which I don't see as related to
>>reusing a TW-TCB in active open. Can you elaborate on this? (In a
>>broader sense, yes, it also deals with the problems caused by Time-wait
>>TCBs. But, I don't see it addess the reuse of Time-wait TCB issue).
>
>
>It deals with the same problem - accumulation of the TIME_WAIT states,
>and provides a set of alternate solutions.
>
>
>>2. RFC 1337 primarily talks about the problems that could occur when 'a
>>new incarnation of a connection is established' without any reference to
>>the 'previous incarnation' (which could result if a TW-TCB is
>>'removed'). I am not proposing to do that.
>
>
>It also addresses, as does the first reference, the purpose of the
>TIME_WAIT itself.
>
>>3. In the example you have given, the old duplicate could result in data
>>corruption even for the same connection, it makes no difference whether
>>the conenction was re-established or not. Basically, without using
>>options (timestamp), there is no way to guarantee that data corruption
>>does not occur for a fast TCP connection. Any connection that wraps
>>around within 2MSL could face data corruption;
>
>
>
>If TCP avoids this using timestamps, how is this handled in your
>variant? First, TCP keeps only IP and port numbers in TIME_WAIT; second,
>while there is a requirement of monotonicity for timestamps within a
>connection, there is no requirement that timestamps be monotonic across
>multiple connections.
>
>Further, the entire mechanism you propose was examined before - see
>the following text from the appendix of RFC1185 (PAWS):
>
>. A different approach was suggested by Garlick, Rom, and Postel
>. [Garlick77].  Rather than using clock-driven ISN selection, they
>. proposed to maintain connection records containing the last ISN used
>. on every connection.  To immediately open a new incarnation of a
>. connection, the ISN is taken to be greater than the last sequence
>. number of the previous incarnation, so that the new incarnation will
>. have unique sequence numbers.
>
>That appendix later explains why this introduces a hazard that even PAWS
>cannot protect:
>
>. However, the connection is still vulnerable to old duplicates in the
>. other direction.  Mechanism (A) prevents trouble in mode F1, but
>. failures can arise in F2, F3, or F4; of these, F2, on short, fast
>. connections, is the most dangerous.
>
>
>>4. In some commonly seen implementations, a TCB is moved from Time-Wait
>>to Syn-Rcvd upon receiving a SYN, if the Sequence number on the SYN is
>>greater than the one received last on the earlier incarnation of the
>>connection. This assumes that the ISN generator on the remote end does
>>not wrap around within 2MSL. If it does, then there is no way to protect
>>the conneciton from data corruption; If it does not, then there is no
>>way the connection could end up with corrupted data. (I am ignoring the
>>128K addition to ISN for now).
>
>
>Common implementation != correct implementation :-)
>There were implementations that did this in 1990 when RFC1185 was
>written as well; they are addressed in the paragraph just before the
>above quote, which describes their failure mode.
>
>
>Joe
>
>
>
>_______________________________________________
>tsvwg mailing list
>[e-mail]
>http://www1.ietf.org/mailman/listinfo/tsvwg


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


_______________________________________________
tsvwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg