Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)

[Randy Stewart <[e-mail]>]

Not getting into the details of vtags.. I think you hit
upon the key point. If you are doing time-wait.. you are
doing time-wait on vtags... aka: 32 bit numbers.

An IP address/Port is NEVER blocked from re-use right away
like it can be in TCP due to time-wait. This was always
one of the most irritating things I did not like in TCP. I
understand the need for it.. but I have been known (in past
lives) while testing things (in a lab) to reboot a machine to
get out of time-wait (due to frustration ;-D)

R
On May 27, 2009, at 9:20 PM, Anantha Ramaiah (ananth) wrote:

> Joe,
>
>>
>>>>> It needs to be pointed out at that, other transport
>> protocols like
>>>>> SCTP doesn't have the TIME-WAIT requirement since the protocol
>>>>> supports in-built mechanisms to deal with the need for the same.
>>>> SCTP has a TIME WAIT state for its connection IDs (socket
>>>
>>> TCB is gone, only the vtag can be in time-wait (some
>> implementations
>>> do it). TIME-WAIT state doesn't exist in the SCTP protocol. Pl see
>>> Randy's and my responses.
>>
>> While I agree that the term "TIME-WAIT" does not appear in
>
> Term, huh? TIME-WAIT is a state in TCP state machine, SCTP doesn't  
> have
> it. Period. As far as SCTP goes the 4 tuple (socket-pair) is never  
> held
> in TIME-WAIT unlike TCP, i.e, you don't have to hold the TCB hanging  
> in
> there for about 2MSL. Now, as Randy explained the vtag alone CAN be  
> held
> in some timewait(again not mandated by the protocol). This is not
> specified in SCTP RFC, nor is the timewait value. SCTP is robust  
> against
> time-wait hazards because of the vtag facility and that is what I  
> meant
> when I said the protocol has "inbuilt mechanisms" for dealing with  
> data
> corruption from an old incarnation (your crash ;-)
>
>> RFC 2690, there is a note:
>
> FWIW, RFC 2690 is obselete. Pl refer RFC 4960.
>
>>
>> " A new Verification Tag value MUST be used each time the
>>   endpoint tears-down and then re-establishes an association to the
>>   same peer."
>>
>> Can you explain how you know that the tag is new unless you
>> hold it for some period of time?
>
> Well, this is purely implementation specific, some imp. can simply  
> be ok
> having a sequential allocation for vtags. Agreed everything isn't
> infinite and there is a wrap up coming into play which can happen if a
> host is trying to make bajillions of connections (open/close), yes you
> can dream up such similar scenarios. The SCTP RFC doesn't say that  
> vtag
> generation needs to be sequential/random (rightfully so, since it is  
> all
> implementation details). The Key point is TCP mandates keeping state
> (active closer) needs to wait for 2MSL whereas SCTP the TCB can be
> freed, and vtag time-wait is optional, and SCTP does not suffer from
> time-wait hazards since vtag protects it.
>
> -Anantha
>

-----
Randall Stewart
[e-mail]