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

From: "sanjay kaniyar" <[email-masked]>
Date: Wed, 24 Oct 2001 01:06:47 -0700

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

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.

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;

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

5. I am not claiming that this problem is the most notable one associated 
with the time-wait state. Nonetheless, it would solve some of the issues I 
have come across in practice.

Sanjay.

>From: Joe Touch <[email-masked]>
>To: sanjay kaniyar <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Tsvwg] TCP Question: Reuse of TCB's in time-wait state:
>Date: Tue, 23 Oct 2001 11:04:43 -0700
>
>
>
>sanjay kaniyar wrote:
>
>>In some operating systems (as well as in Richard Steven's TCP/IP
>>illustrated), I have come across ways to reuse a TCB in time-wait state.
>
>
>Lars already pointed out some of our earlier work on TCB reuse, and the
>issues therein. However, when reusing a TIME_WAIT, there are other
>issues, addressed in the following two papers"
>
>"The TIME-WAIT state in TCP and Its Effect on Busy Servers,"
>Theodore Faber, Joe Touch, and Wei Yue, Proc. Infocom '99, pp.
>1573-1583. http://www.isi.edu/touch/pubs/infocomm99/
>
>Bob Braden's "TIME-WAIT Assassination Hazards in TCP," RFC-1337, May 1992.
>
>
>>The scenario is, when a SYN is received for a time-wait TCB with an ISN
>>greater than the last sequence number seen on that in the receive
>>direction, the TCB is moved back into the SYN-RCVD state, and the three
>>way handshake proceeds as usual (with the ISN on the SYN+ACK sent out
>>being equal to the last sequence number used in the send direction + 
>>128K).
>
>
>The TIME_WAIT is intended to prevent data from an old connection from
>creeping into a new connection undetected. Using a new ISN doesn't
>prevent this; data from an old connection, prior to a wraparound, could
>still be in the network - e.g.,
>
>	*old data seq 32000 - bubbles around in the net
>	(the rest of the seq space is used and wraps)
>	old connection closes with seq 31000
>
>	(time wait with seq 31000)
>
>	new connection opens with seq 31001
>	old data (*) arrives and is accepted on the new connection
>
>The reuse of TCBs is based on IP addresses and port numbers only, not
>sequence numbers. This is one reason why.
>
>>One such possible way to implement this would be, to move the TCB from
>>time-wait to SYN-SENT state and send out a SYN with an ISN greater than
>>the last send sequence number seen on the TCB. If the peer responds with
>>an ISN greater than the one last seen by the TCB in the receive
>>direction, the connection establishement proceeds normally; Otherwise,
>>send a RST, abort the connection request and put the TCB back in the
>>time-wait state.
>
>
>TIME_WAIT problems are usually unidirectional; using TW information to
>open a connection doesn't solve the problem that's most notable. That
>said, this can still have data from old connections creep into new ones.
>
>Joe
>

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

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

---

From: Joe Touch <[email-masked]>
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.

> 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