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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ananth,

Please see Randy's post.

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

SCTP is *not* robust unless you hold at least the socket pair + vtag
tuple* in some wait state. Holding just the vtag is perhaps less work,
but inhibits more connections than holding the true connection ID (the
socket pair + vtag tuple).

* (that's not the TCB, FWIW - TCBs have all sorts of other stuff (time
since last packet sent, RTT estimates, etc.)

Without holding some sort of wait state, there is NO inbuilt mechanism
that avoids corruption from an old connection. The *assumption* is that
the vtags are not reused in sequence.

Joe


> 
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoeELgACgkQE5f5cImnZrtuwQCfQ4sgIID87v0Rulp1iDL4AaRM
tDYAn2/Y6Xzu+0dHfARu/iXLW4E8Kh/T
=Q/pu
-----END PGP SIGNATURE-----