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

From: "sanjay kaniyar" <[email-masked]>
Date: Wed, 24 Oct 2001 23:48:08 -0700

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 <[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: 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
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg

_________________________________________________________________
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: Thu, 25 Oct 2001 09:10:32 -0700

sanjay kaniyar wrote:

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

Perhaps you can clarify this. RFC 1185 explicitly mentions the 
following; isn't FIN+1 the same think as rcv_next?

. Old duplicates in one direction can be avoided by
. choosing the ISN to be the next unused sequence number from the
. preceding connection (i.e., FIN+1); this is essentially an 

. application of the scheme of Garlick, Rom, and Postel, using the
. connection block in TIME-WAIT state as the connection record.

Then goes on to state:

. other direction. 

It seems like your ISNreverse = snd_next + 128K is intended to avoid 
this problem, however, the entire sequence space could have been in 
flight (and then some).

It seems like you'd have to ensure that both ends of the connection have 
  ISNs _AND_ timestamps which are valid for restarting. Restoring a 
TIME_WAIT state can, at best, ensure this only for the side that kept 
the TIME_WAIT.

Joe

---

From: Kevin Lahey <[email-masked]>
Date: Thu, 25 Oct 2001 10:58:48 -0700

On a related topic, a few months ago I was browsing the Linux source,
to see what they were doing about time-wait state information 
compression.  It looked like they were dynamically adjusting
the time-wait for connections based on the RTT.  

Could anybody comment on this scheme?  Perhaps I just mis-read the
source?

Kevin
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Oct 2001 11:37:02 -0700

Kevin Lahey wrote:

> Could anybody comment on this scheme? 

If so, that would be unfortunate. The TIME_WAIT is based on the MSL, not 
the RTT. The MSL is the longest a packet _could_ float around _anywhere_ 
in the net and end up back at the destination. RTT of the particular 
connection isn't relevant.

Joe