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

[Randy Stewart <[e-mail]>]

On May 28, 2009, at 12:14 AM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Randy Stewart wrote:
>> 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.
>
> Sorry, maybe I'm missing this.
>
> Let A=srcIP, X=srcport, B=dstIP, Y=dstport.
>
> In TCP, if I use A,X->B,Y, then close the connection, I cannot use it
> for another 2 minutes.
>
> In SCTP, if I use A,X->B,Y with Vtag Q, then close the connection,
> clearly I cannot use A,X->B,Y with Vtag Q again for some (unspecified,
> AFAICT, in the specs) period of time.
>
> You appear to be claiming that what SCTP does is block Vtag Q for that
> period of time _for all_ socket pairs. That's strictly worse than TCP
> was doing.
>
> E.g., TCP has 32 + 16 + 32 + 16 bits to play with for connections as a
> whole, i.e., 96 bits. SCTP would have only 32. A large server with a  
> lot
> of short connections could easily have vtag collisions in that  
> situation.


No actually Q is blocked ONLY for the socket pair
A,X -> B,Y for 2MSL.



>
>
>> 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)
>
> Sure - and what I'm claiming is that not having (or not holding) true
> time-wait in SCTP puts you in the same boat as you were in TCP when  
> you
> spin the MSL timer down. In both cases you're betting that old packets
> won't come into the new connection - and, as I noted, with routers
> stalling to handle interruptions - things are getting worse along  
> those
> lines, not better.


And that is why Vtags are time waited in SCTP... I understand
the issue.. but often times in lab conditions its an annoying
pain to deal with ;-)


R


>
>
> Joe
>
>> 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]
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoeD70ACgkQE5f5cImnZruySACfdm9p30W0GcuKaBUJ6rKoXxBL
> lm4AoNrFpWuRY8BCMw6R8/5wtyPfztOv
> =5uhf
> -----END PGP SIGNATURE-----
>

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