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

[Randy Stewart <[e-mail]>]

Joe:

In-line..


On May 27, 2009, at 12:50 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Anantha Ramaiah (ananth) wrote:
>>
>>>> Any RFC compliant TCP implementation will honor TIME-WAIT
>>> requirement
>>>> and that involves keeping state at the side which initiated the
>>>> connection close.
>>> It's worth noting that many implementations aren't RFC
>>> compliant in this regard, though.
>>
>> Which TCP implementation is not honoring TIME-WAIT state (BSD, Linux,
>> our implementations etc., all honor TIME-WAIT requirement)? The only
>> thing is that the "ancient" 2MSL value can be configurable. 2MSL is
>> getting adapted to modern networks and in some intranet cases this  
>> value
>> is configured to be very small, FWIW.
>
> RFC793 specifies MSL as 2 minutes, and it is not "configurable". In
> terms of following the specification, that's where most  
> implementations
> fail.
>
> Many modern networks actually take advantage of this MSL when they do
> not flush their buffers during short-term outages. In networks with  
> such
> paths - e.g., users on cellphones that go through tunnels, etc. -  
> RTT is
> not a reasonable estimate of MSL.
>
>>>> It is also well known that the side-effect of TIME-WAIT requirement
>>>> leads for the 4-tuple (socket-pairs) to be locked for some time.
>>> That is not a "side effect", that is the *desired* effect.
>>
>> The reason I use the term "side effect" is beause if the TIME-WAIT  
>> state
>> deosn't exist, your port reuse factor aka connection acceptance rate
>> (for the same socket pair) gets increased. YMMV.
>
> If TIME-WAIT doesn't exist, your potential to have data from an old
> connection corrupt a new connection also increases, and you no longer
> have a reliable protocol. If you call that "mileage", sure; I call  
> that
> a crash ;-)
>
>>>> 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 RFC 2690,
> there is a note:
>
> " 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?



Basically for BSD we take a v-tag used in a connection.. call it 'X',  
and
we place just the tag 'X' into a "timed-wait" cache for 2MSL. There is  
no
restriction on the socket here.. just the tag 'X' will not be used again
with this socket.

So say the socket did the following:

sd = socket(..., ONE-2-MANY)

/* setup events .. not shown */

sd = sctp_connectx(ip-z, &assoc-id);

<---At transport layer Vtag=X --->

sctp_sendmsg(some-mesg, size,... assoc-id);

... some time later
sctp_sendmsg(SCTP_EOF, assoc-id);

<---SHUTDOWN is sent, and at conclusion
     the V-tag'X' is placed in timed-wait.

<-- event returned telling you the association is gone.

Then right away (less than 2MSL).. app does

sd = sctp_connectx(ip-z, &assoc-id);

<- Transport layer randomly picks a new vtag but CANNOT use 'X'
    (its in the time-wait cache).. so it uses 'Y'.

sctp_sendmsg(hello-again, size, ..., assoc-id);


Note that In theory I did not even need to have the "connectx calls"  
since
SCTP will setup the association implicitly ... I added these for clarity
in this email ;-)


So basically the socket/port and peer socket/port is re-used right  
away with
the restriction being that the vtag 'X' cannot be used.

Hope that clears up the issue  :-)

R




>
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkodb04ACgkQE5f5cImnZruWNwCfUx8QgBSsjEo2zKsRuFtykbpp
> 4DQAmwaWCj0UjpRscD8aOwx4Xznkq2xa
> =WP09
> -----END PGP SIGNATURE-----
>

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