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

[Michael Tüxen <[e-mail]>]

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:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> 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
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkoerkcACgkQE5f5cImnZrvVlQCgoNoQPGril0N687ocbOD1n0ex
>> cUoAn35PgtR+ogd0NGkkPZBD74H39MzN
>> =uJLP
>> -----END PGP SIGNATURE-----
>>
>
> -----
> Randall Stewart
> [e-mail]
>
>
>
>
>