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

[Joe Touch <[e-mail]>]

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



Michael Tüxen wrote:
> 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.

Sure - I'd be glad to assist...(NB to the chairs/ADs: yes, only after
TCP-AO is revised, which is coming shortly).

Joe

> 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.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKHtVlE5f5cImnZrsRAqHoAKDsl5HEu8HofMt/lctf7T56SGPE+gCcDEiF
ePu1FlP4Qywik8K04cjtm7A=
=SOzA
-----END PGP SIGNATURE-----