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

sanjay kaniyar wrote:

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

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:

. However, the connection is still vulnerable to old duplicates in the
. 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

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
http://www1.ietf.org/mailman/listinfo/tsvwg