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

[Randy Stewart <[e-mail]>]

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]