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

[Joe Touch <[e-mail]>]

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



Anantha Ramaiah (ananth) wrote:
> Randy/Michael :
>  My suggestion here would be :
> 
> Suppose you are going to specify the timewait of vtags in the spec
> etc., I would like the following point to be considered (debated in the
> list):
> - Just not repeat the same thing done for TCP i.e, 2MSL (4 minutes!).
> 
> 2MSL time was considered the "safe and conservative time" for the old
> segments to be drained out of the network in 1981. Now this timewait
> value is, needless to say, is ultra-conservative for modern networks and
> SCTP being a modern transport protocol, should consider more thought
> while choosing the empirical value. Almost every implementation out
> there provides a knob and nobody waits for 4 minutes as far as TCP is
> concerned. FWIW.

Right. 2MSL might be way too short, given how new systems 'stall' for
longer periods of time -- e.g., as I noted how routers don't flush
queues when on trains going through tunnels.

While I agree that 2MSL might be incorrect as a value, there might be
good reason to *increase* the "do not repeat" period as well, as a
result of such "modern" environments.

Joe

>> -----Original Message-----
>> From: Michael Tüxen [mailto:[e-mail]] 
>> Sent: Thursday, May 28, 2009 10:55 AM
>> To: Joe Touch
>> Cc: James Polk (jmpolk); Randy Stewart; Anantha Ramaiah 
>> (ananth); tsvwg; [e-mail]; Fernando Gont
>> Subject: Re: [Tsvwg] WGLC for Port Randomization starts now 
>> (April 1st)
>>
>> Hi Joe,
>>
>> just a clarification:
>>
>> * timewait for vtags is currently no described in
>>    any SCTP specification.
>> * the need for this kind of feature came up
>>    several times.
>> * Randall describes what is used implemented in
>>    FreeBSD and it does take the port number pair
>>    into account.
>> * Since an SCTP endpoint can have multiple addresses
>>    and these addresses can change over time, addresses
>>    are not considered in the FreeBSD implementation.
>>
>> Looking at the discussion, I think we need to write up an ID 
>> describing this stuff. This would also clarify things for 
>> other implementations which do not have this kind of stuff at all.
>>
>> Best regards
>> Michael
>>
>> On May 28, 2009, at 5:45 PM, Randy Stewart wrote:
>>
>>> On May 28, 2009, at 11:31 AM, Joe Touch wrote:
>>>
> 
> 
> Randy Stewart wrote:
>>>>>> On May 28, 2009, at 11:11 AM, Joe Touch wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Randy Stewart wrote:
>>>>>>>>> Joe:
>>>>>>>>>
>>>>>>>>> In-line..
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>> 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 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  :-)
>>>>>> Yes, but it also underscores my concern. What you did was 
>>> basically:
>>>>>>   - increase the space available to a single service from
>>>>>>   a single IP address
>>>>>>       going from TCP's 16 bits (max) of source port to
>>>>>>       48 bits of source port + vtag
>>>>>>
>>>>>>   - *decrease* the space available for different
>>>>>>   services from different IP addresses
>>>>>>       going from TCP's 32 bits of address +
>>>>>>       16 bits of source port + 16 bits of
>>>>>>       dest port (64 bits) down to only 32
>>>>>>
>>>>>>> Joe:
>>>>>>> I don't follow your meaning here..
>>>>>>> I can have
>>>>>>> IP-A Port-X Vtag-Y <---->
>>>>>>> and
>>>>>>> IP-A Port-Y Vtag=Y <---->
>>>>>>> existing simultaneously... so I don't see how this decreased the 
>>>>>>> space for services from different IP addresses...
> OK so there's two cases:
> 
> 	1) the vtag is the unique thing held (NO OTHER STATE)
> 	2) the vtag is held in the context of the socket pair
> 
> In 1), the vtag effectively is the connection ID.
> 
> In 2), the connection ID is the 5-tuple of 
> [srcIP,srcport,dstIP,dstport,vtag]
> 
> In the case of 1), you decrease the space available for 
>>> connections 
> vs.
> TCP when you include connections from different machines and for 
> different services.
> 
> In the case of 2), you increase the space available, and I 
>>> don't have 
> the concern raised above.
>>>>
>>>>
>>>> Ok, I just went out and looked at the code (sometimes its good to 
>>>> refresh your memory ;-D)
>>>>
>>>> Basically the vtag cache holds:
>>>>
>>>> 1) Vtag
>>>> 2) Source port
>>>> 3) Destination port
>>>> 4) A timestamp when the entry expires.
>>>>
>>>> This is all hashed on SrcPrt+DstPrt+Vtag-in-time-wait.
>>>>
>>>>
>>>> So when I go to create a new association, I
>>>>
>>>> 1) Randomly generate a vtag e.g. R
>>>> 2) Hash R+local-port+Peer-port
>>>> 3) Use hash to look in vtag time wait block.
>>>> 4) If found goto 1
>>>>   else use vtag-R
>>>>
>>>>
>>>> The IP addresses themselves are not saved in this. Could they be, 
>>>> sure, we just decided not to... since one would then have to have a 
>>>> "set" of IP addresses and a port on each side... and that seemed 
>>>> unneeded. Of course, as I said, most implementations have no 
>>>> timed-wait on anything.. which we in theory could do by setting the 
>>>> Time = 0... so they expire right away... But I don't think that is 
>>>> wise.
>>>>
>>>> It might even be wise to go back and expand the hash to 
>>> include the IP 
>>>> addresses of the peer...
>>>> since this simpler approach does limit the vtags somewhat... i.e. a 
>>>> peer connecting to a server from a same port could not use a vtag 
>>>> thats in time-wait...
>>>> which is not
>>>> strictly correct...
>>>>
>>>>
>>>>
>>>> R
>>>>
> 
> I am still a bit confused as to which case is true; you 
>>> appeared to 
> give two different responses.
> 
> Joe
>>>>
>>> -----
>>> Randall Stewart
>>> [e-mail]
>>>
>>>
>>>
>>>
>>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoe8y8ACgkQE5f5cImnZrvnpgCcCgx3lLpt7sLdF3t+3FTMacKK
+7cAoOl1mJpTZdUd7ky9WsA8ER9AzujX
=UHc6
-----END PGP SIGNATURE-----